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Abstract 

The  goal  of  this  study  was  to  design,  develop,  test,  and  evaluate 
an  initial  prototype  information  system  to  enhance  the  conduct  and 
management  of  research  in  the  School  of  Systems  and  Logistics  at  the  Air 
Force  Institute  of  Technology  (AFIT) .  To  accomplish  this  goal,  the 
authors  developed  the  prototype  system  based  on  a  methodology  that  v/as 
generally  patterned  after  the  milestones  in  a  typical  system  development 
life  cycle.  The  "proof -of -concept"  nature  of  this  research  caused  the 
researchers  to  map  the  study's  seven  major  objectives  into  a  second 
system  development  model  called  the  Spiral  Model  (Boehm,  1988:61).  This 
hybrid  model  provided  better  defined  steps  in  a  model  that  allows  for 
iterative  prototyping  and  served  as  the  framework  for  this  project. 

This  study's  objectives  were  completed  by  collecting  data  using  a 
structured  interview,  literature  review,  requirements  validation  effort, 
and  a  prototype  evaluation  questionnaire.  The  analytical  portions  of 
the  research  included:  (1)  an  examination  of  alternatives  to  building 
the  prototype;  (2)  the  selection  of  automation  requirements  and 
prototype  architecture;  and  (3)  a  determination  of  the  prototype's 
technical  adequacy  and  suitability. 

The  prototype  AFIT  Research  Management  System  (ARMS)  produced  by 
this  study  is  comprised  of  four  major  subsystems :  the  Research  Topic 
Selection  Subsystem,  Research  Products  Reuse  Subsystem,  Research 
Management  Subsystem,  and  Database  Administration  Subsystem.  An 
operational  test  of  the  first  three  subsystems  was  completed  using  a 
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series  of  demonstrations  that  were  attended  by  47  graduate  students  and 
11  faculty  members.  An  analysis  of  the  questionnaires  completed  by  the 
testers  validated  the  desirability  of  the  system  concept  and  provided 
many  recommendations  for  improving  it.  Recommendations  for  research 
were  developed  concerning  the  follow-on  development  of  the  prototype  and 
the  conduct  of  corollary  studies.  The  corollary  studies  listed  in 
Chapter  V  represent  a  number  of  key  issues  that  should  be  addressed 
prior  to  implementing  an  advanced  prototype  or  operational  system. 


DEVELOPMENT  OF  A  PROTOTYPE  AIR  FORCE  INSTITUTE  OF  TECHNOLOGY 
(AFIT)  RESEARCH  MANAGEMENT  SYSTEM  (ARilS) 

Introduction 


General  Issue 

The  goals  of  increased  productivity  and  process  improvement  have 
received  considerable  attention  during  this  century.  The  literature 
suggests  that  most  of  these  efforts  have  concentrated  on  achieving 
immediate  economic  results  in  manufacturing  operations,  rather  than 
"non-manufacturing"  endeavors  such  as  research  (Tenner,  1991:27), 
However,  research  has  been  significantly  enhanced  during  recent  years 
through  the  increased  use  of  computer  technology  (Straub  and  Beath, 
1990:30).  A  major  contributor  to  this  progress  was  the  application  of 
computerized  databases  as  "information  delivery  systems"  (Straub  and 
Beath,  1990:30).  The  general  success  of  past  automation  efforts, 
combined  with  the  dynamic  nature  of  computer  science,  suggests  that 
future  gains  in  researcher  productivity  may  be  derived  from  the  further 
application  of  information  systems  and  other  computer  science 
techniques . 

Bac)cqround 

The  current  state  of  research,  in  academe  and  industry,  indicates 
a  strong  need  for  improvement.  John  Gilman,  a  forty-year  veteran  in  the 
field  of  research,  estimates  that  approximately  ninety  percent  of  all 
research  conducted  does  not  lead  to  recognizable  benefits.  Despite  this 
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bleak  appraisal,  research  can  still  be  profitable  if  the  available 
resources  (funds,  personnel,  facilities,  and  equipment)  are  managed 
effectively  (Gilman,  1991:44). 

The  literature  posits  that  good  research  management  is  practiced 
by  facilitating  researcher  creativity  and  productivity  rather  than 
strictly  directing  results.  A  practical  and  proven  approach  to  this 
situation  is  to  build  and  cultivate  a  research  environment  that ; 

1.  Creates  new  technical  ideas  by  first  assimilating  existing 
ideas  and  combining  them  in  new  ways . 

2.  Remains  focused  during  "failures”  while  striving  for  state  of- 
the-art  results. 

3.  Possesses  (or  has  access  to)  first-rate  technical,  analytic, 
library,  and  other  services  and  equipment. 

4.  Provides  for  effective  communications  among  researchers, 
between  researchers  and  other  members  of  the  organization,  and 
outward  to  sponsors.  (Gilman,  1991:47) 

In  striving  to  meet  similar  objectives  at  the  Air  Force  Institute 
of  Technology  (AFIT)  School  of  Systems  and  Logistics  (LS),  the  faculty 
has  earnestly  examined  and  is  still  evaluating  several  research  program 
enhancements.  The  faculty’s  efforts  have  resulted  in  improvements 
within  the  areas  of  academic  research  education  and  informal  guidance 
("tips  and  techniques"  newsletters)  dissemination  (Emmelhainz,  1991c) 

One  of  the  most  significant  enhancement  efforts  was  the  recent 
implementation  of  the  "team  thesis."  Under  this  initiative,  research 
teams  of  two  students  are  guided  by  an  advising  committee  with  two  or 
nrare  faculty  members.  The  goals  of  the  team  thesis  include:  the 
improvement  of  the  students'  capabilities  to  examine  problems  of  greater 
scope  and  significance;  the  promotion  of  greater  objectivity  in  research 
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studies:  and  the  enhancement  of  the  thesis  advising  process  (Emmelhainz, 
1931c) . 

Despite  the  potential  "manpower"  benefits  offered  by  the  team 
thesis,  this  technique  does  not  address  inany  difficulties  that 
inherently  affect  student  researcher  productivity  (Emmelhainz,  1991c)  . 

A  detailed  description  of  the  most  important  difficulties  is  provided  in 
Chapter  II .  The  intent  of  this  study  was  to  examine  two  such 
difficulties,  research  topic  selection  and  research  product  reuse,  and 
to  develop  a  prototype  system  that  would  assist  future  student 
researchers  by  automating  a  portion  of  these  functions.  A  prime 
consideration  in  the  selection  of  these  two  items  was  their  description 
in  the  literature  as  key  tasks  in  the  academic  research  process  (Allen. 
1973 : viii, 11,  and  51;  Madsen,  1983:21;  Emory  and  Cooper,  1991:76). 

Early  in  this  study,  the  authors  recognized  that  the  detailed 
level  of  information  contained  in  the  proposed  prototype  system  could  be 
used  to  automate  several  AFIT  LS  research  management  tasks .  This 
insight  led  the  authors  to  include  some  rudimentary  procedures  for 
selected  research  management  tasks.  More  importantly,  it  resulted  in 
the  development  of  a  design  to  facilitate  future  incremental  expansion 
as  additional  areas  of  the  research  domain  are  examined  and  automated 

Specific  Research  C-.Qa I 

The  goal  of  this  research  project  was  to  design,  develop,  test, 
and  evaluate  an  initial  prototype  information  system  to  enhance  the 
conduct  and  management  of  research  in  the  School  of  Systems  and 
Logistics  at  the  Air  Force  Institute  of  Technology. 
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RgSgargh  Objectives 


This  study's  research  objectives  were  generally  patterned  after 
the  milestones  in  a  typical  system  development  life  cycle  (Senn, 
1984:17).  However,  the  "proof -of -concept"  nature  of  this  study  led  the 
authors  to  also  view  these  objectives  as  part  of  a  meta -model  called  the 
spiral  life  cycle  model  for  system  development  (Boehm,  1988:61-72).  By 
doing  so,  the  authors  were  identifying  this  research  as  the  initial 
phase  in  an  effort  that  would  require  continued  study.  The  specific 
application  of  the  spiral  model  in  this  project  and  justification  for 
its  selection  are  further  explained  in  Chapters  II  and  III. 

The  following  specific  objectives  guided  the  completion  of  this 
research  project: 

1.  Describe  the  current  AFIT  research  environment. 

2.  Define  and  validate  the  AFIT  Research  Management  System  (ARMS) 
requirements . 

3.  Analyze  alternatives  and  select  prototype  constraints. 

4 .  Design  and  develop  the  prototype  system. 

5.  Perform  an  operational  test  of  the  prototype  system. 

6 .  Analyze  and  interpret  operational  test  results . 

7.  Develop  recommended  path  for  follow-on  research. 

Each  of  these  objectives  involved  the  completion  of  two  or  more 
component  steps,  which  are  described  in  Chapter  III. 

Limitations 

Due  to  time  constraints,  the  initial  prototype  could  not  encompass 
all  validated  requirements.  Therefore,  the  design  of  the  ARMS  contains 
only  those  requirements  deemed  necessary  to  determine  the  feasibility 
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and  suitability  of  the  system.  The  selection  process  used  to  determine 
the  representative  capabilities  for  this  version  of  the  prototype 
strongly  favored  implementing  the  requirements  related  to  student 
researcher  productivity  and  proving  the  system's  overall  suitability  to 
enhance  the  AFIT  research  environment . 

Since  the  goal  of  this  study  was  "proof-of-concept"  oriented,  a 
formal  strategy  for  implementing  and  managing  a  "production-quality" 
system  was  not  developed.  However,  a  discussion  of  several  practical 
recommendations  is  provided  in  Chapter  V.  Similarly,  this  study  does 
not  provide  solutions  to  the  problems  associated  with  implementing  and 
managing  reuse  programs,  as  described  in  Chapter  II. 

The  development  tools  used  to  implement  the  prototype  system  were 
limited  to  those  available  at  AFIT  during  the  time  of  the  study.  This 
restriction  was  self-imposed  to:  (1)  use  the  available  "in-house" 
expertise  within  the  AFIT  Directorate  of  Communication  and  Computer 
Systems;  (2)  maximize  the  prototype's  reusability  for  future  research 
and  improvement  efforts;  and  (3)  minimize  the  cost  of  the  project. 

Assumptions 

In  completing  this  study,  the  authors  assumed  that  their  status  as 
student  researchers  qualified  the  contributions  they  made  in  formulating 
the  requirements  for  the  ARMS.  Additionally,  the  authors  based  several 
prototype  implementation  decisions  on  their  previous  information  systems 
development  experiences.  However,  information  system  experts  from  the 
AFIT  faculty  and  support  staffs  were  consulted  on  some  critical 
decisions  related  to  the  prototype's  extendibility . 
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Contributions  2X  the  Research 

Three  specific  areas  of  research  were  addressed  during  the 
development  of  the  prototype  ARMS:  research  topic  selection,  research 
products  reuse,  and  research  management.  Each  of  these  areas  was 
treated  as  an  equal  subsystem  of  the  prototype  throughout  the  conduct  of 
this  research.  A  synopsis  of  the  justification  for,  and  benefits  of, 
this  study  is  provided  in  this  section. 

Research  Topic  Selection .  The  current  method  of  researching 
potential  academic  research  topics  primarily  involves  the  use  of  manual 
procedures.  The  available  automated  systems  provide  general  access  to  a 
variety  of  past  studies,  but  do  not  supply  information  concerning 
ongoing  research  or  new  requests  for  research.  Within  the  context  of 
the  current  AFIT  research  environment  (described  in  Chapter  II),  the 
automation  of  these  two  key  sources  of  information  will  help  .AFIT  LS 
student  researchers ; 

1.  Begin  the  process  of  selecting  and  formulating  a  research 
topic  earlier  in  their  graduate  program. 

2.  Review  a  broader  range  of  research  topics  more  expediently  and 
efficiently . 

3.  Scope  their  selected  research  problem. 

4.  Select  topics  that  lend  themselves  to  longitudinal  study. 

The  final  implementation  of  the  ARMS  Research  Topic  Selection  Subsystem 
(RTSS)  could  also  increase  the  school's  potential  for  qualitative  and 
quantitative  gains  in  the  areas  of  continuing  research  studies  and  the 
communication  of  research  needs. 

Research  Products  Reuse .  This  study  also  adapted  and  applied  an 
emerging  computer  science  technique  called  software  reuse  This 
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technique  is  commonly  defined  as  "the  use  of  previously  acquired  or 
developed  concepts  and  objects  in  a  new  situation"  ( Prieto-Diaz , 

1987:7).  In  the  area  of  software  development,  reuse  concepts  and 
objects  are  major  components  or  products  that  comprise  the  overall 
system,  such  as  source  code  modules,  program  architectures,  and 
documentation  (Jones,  1984:488-489).  The  analogous  application  of  this 
technique  to  the  academic  research  domain  yielded  the  following  types  of 
reusable  components:  data  collection  instruments,  data  sets,  statistical 
models,  computer  programs,  and  other  products. 

The  current  practice  of  cataloging  only  the  thesis  document 
inhibits  the  reuse  of  such  components  for  two  main  reasons:  (1)  they  are 
often  difficult  to  locate,  and  (2)  they  normally  require  extensive 
manual  effort  to  recreate.  The  Research  Products  Reuse  Subsystem  (RPRS) 
developed  as  part  of  this  study  represents  an  initial  attempt  at 
cataloging,  tracking,  and  managing  research  products  for  the  purpose  of 
facilitating  their  location,  review,  and  reuse  by  students.  It  was  not 
possible  to  determine  the  quantitative  value  of  the  RPRS  during  tliis 
study,  but  the  operational  test  results  indicate  that  it  could  provide 
productivity  gains  similar  to  those  experienced  with  software  reuse. 

Research  Management ■  During  early  discussions  of  this  project 
with  the  research  director  in  each  AFIT  school,  the  authors  became  aware 
of  an  inherent  need  for  a  well-structured,  reliable  source  of  research 
program  information.  As  focal  points  for  summarizing  and  formally 
reporting  each  school's  research  efforts,  the  directors  employ  several 
unique  automated  and  non-automated  systems.  The  format,  collection,  and 
management  of  academic  research  information  varies  widely  for  eacli 
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current  system.  In  addition,  the  systems  provide  little  or  no  trend¬ 
tracking  capability  and  do  not  offer  an  integrated  view  of  the 
respective  research  programs. 

The  prototype  design  for  the  ARMS  Research  Management  Subsystem 
(RMS) ,  combined  with  the  two  ARMS  subsystems  described  above,  integrates 
most  of  the  data  elements  currently  spread  across  several  inflexible, 
single-purpose  databases  managed  by  the  AFIT  LS  Thesis  Program 
Administrator.  The  querying,  reporting,  and  managing  facilities 
implemented  in  the  RMS  provide  a  general  framework  which  can  be  expanded 
and  refined  during  future  research  efforts.  The  potential  productivity 
gains  offered  by  the  RMS  are  not  measurable  at  this  time  and  could  be 
tempered  by  the  administrative  overhead  required  to  learn  and  maintain 
the  system.  Future  research  should  examine  the  overall  system  in  terms 
of  a  cost-benefit  analysis. 

Sequence  Prggcnt^tibn 

This  report  is  divided  into  five  chapters.  This  chapter  provided 
a  description  of  the  study's  background,  specific  research  goal, 
research  objectives,  and  limitations.  Chapter  II  contains  a  description 
of  the  current  AFIT  LS  research  environment  and  presents  a  literature 
review  in  the  areas  of  research,  reuse,  and  information  systems. 

Chapter  III  describes  the  methodology  used  to  meet  the  seven  objectives 
of  this  study.  Chapter  IV  reviews  the  specific  research  findings  as 
they  relate  to  each  objective  described  in  Chapter  III.  Chapter  V 


provides  conclusions  and  offers  recommendations  for  further  researcli. 


The  goal  of  this  research  was  to  design,  develop,  test,  and 
evaluate  a  prototype  information  system  to  enhance  the  conduct  and 
management  of  academic  research  at  the  Air  Force  Institute  of  Technology 
(AFIT)  School  of  Systems  and  Logistics  (LS) .  To  support  this  end,  the 
three  major  areas  which  comprise  the  study's  problem  domain  and  solution 
components- -research,  reuse,  and  information  systems  - -were  examined. 

This  chapter  begins  with  a  review  of  the  overall  AFIT  and  LS-specific 
research  programs,  and  then  turns  to  a  discussion  of  some  major 
difficulties  facing  student  researchers.  The  next  section  describes  the 
concept  of  reuse  and  how  it  contributed  to  this  project's  theoretical 
foundation.  The  final  section  of  this  chapter  discusses  basic 
information  system  principles  and  the  life  cycle  model  employed  to 
develop  the  prototype  ARMS. 

Research 

The  term  "research"  has  diverse  meanings  depending  on  the 
situation  and  discipline  of  its  practitioners  (Lindsay  and  Neumann, 
1988:32).  As  a  result,  the  literature  contains  a  variety  of  definitions 
and  countless  guidelines  for  conducting,  managing,  evaluating,  and 
funding  research.  To  gain  an  understanding  of  the  research  program  at 
AFIT,  the  authors  conducted  a  structured  interview  with  the  research 
director  for  each  of  AFIT's  three  schools.  The  interview  results  were 
analyzed  in  light  of  the  current  literature  on  research  to  complete  this 


section  and  research  objective  one. 


AFIT  Research  Program.  The  formal  mission  of  AFIT  is  to  "support 


national  defense  through  graduate  and  professional  education  and 
research  programs"  (AFIT,  1990:1-1).  At  the  start  of  this  study,  .i.FIT 
was  comprised  of  several  support  directorates  and  three  resident 
schools:  the  School  of  Systems  and  Logistics  (LS),  School  of  Engineering 
(EN) ,  and  School  of  Civil  Engineering  and  Services  (DE) .  Several 
changes  have  occurred  in  that  organizational  structure  during  the  past 
year,  but  the  overall  mission  of  the  Institute  remains  the  same. 

Research  Environment .  Research  is  an  integral  part  of  the 
AFIT  mission  and  is  conducted  by  both  faculty  and  students .  Faculty 
research  ensures  the  currency  of  course  content,  promotes  tlie  continued 
intellectual  growth  of  the  faculty,  contributes  to  a  discipline's  body 
of  knowledge,  and  meets  the  specific  needs  of  the  United  States  Air 
Force  (USAF)  and  Department  of  Defense  (DoD) .  The  primary  purpose  of 
student  research  is  to  enrich  the  overall  educational  experience  by 
contributing  to  a  discipline's  body  of  knowledge  and  the  missions  of  the 
USAF  and  DoD  (AFIT,  1990:1-5). 

Each  resident  school  has  a  research  director  to  coordinate  ongoing 
research  programs  (AFIT,  1990:X-1).  The  directors  have  two  sets  of 
responsibilities;  one  for  managing  the  external,  or  promotional,  aspects 
of  the  research  program,  and  a  second  for  administering  the  internal 
aspects  of  the  program.  The  main  external  responsibilities  of  these 
directors  are : 

a.  to  make  [their  school]  an  effective  part  of  the  problem¬ 
solving  capability  of  the  Air  Force; 

b.  to  make  the  Air  Force  fully  aware  of  [their  school's] 
capabilities  in  research  and  consultations; 
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c.  to  help  obtain  funding  and  other  forms  of  research 
sponsorship;  and 

d.  to  serve  as  ombudsman  for  research  bottlenecks.  (Bridgman, 
1991;  Duncan,  1991;  Emmelhainz,  1991a) 

The  research  directors'  internal  responsibilities  are  discussed  later  in 

this  section. 

Similarities  Among  School  Research  Programs .  Personal 
interviews  conducted  with  the  research  directors  highlighted  several 
program  similarities.  All  three  directors  strongly  affirmed  the  need 
for  research  to  be  faculty-driven.  Accordingly,  they  agreed  that 
faculty  consulting  work  with  USAF  and  DoD  agencies,  as  well  as  contacts 
with  other  professionals,  should  serve  as  the  basis  for  both  faculty  and 
student  research.  However,  two  of  the  three  research  directors 
indicated  that  student  research  was  not  currently  guided  by  this 
approach  in  their  respective  schools  (Bridgman,  1991;  Duncan,  1991; 
Emmelhainz,  1991a) . 

Another  similarity  among  the  DE,  EN,  and  LS  research  programs  was 
the  "passive"  internal  management  style  practiced  by  the  research 
directors.  Each  director  espoused  the  often  described  approach  in  the 
literature  of  providing  the  needed  resources  and  then  letting  the 
practitioners  conduct  their  research  studies  with  minimal  oversight.  In 
this  role,  the  directors  and  their  staffs  serve  as  collection  points, 
storehouses,  and  dissemination  points  for  information  (Bridgman,  1991; 
Duncan,  1991;  Emmelhainz,  1991a) . 

Two  of  the  more  prolific  "information  handling"  activities 
performed  by  the  research  directors  and  their  staffs  are  the  "call  for 
thesis  topics"  and  development  of  inputs  for  the  annual  report,  "AFIT 
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Contributions  to  Air  Force  Research  and  Consulting."  The  first  activity 
is  conducted  annually  to  canvass  DoD  organizations  for  pertinent 
research  topics.  Its  purpose  is  to  complement  the  supply  of  topics 
generated  through  faculty  research  and  consulting.  The  latter  activity 
is  a  post-academic  year  effort  to  summarize,  assess,  and  formally  report 
the  contributions  made  by  AFIT  faculty  and  student  researchers 
(Bridgman,  1991;  Emmelhainz,  1991a) . 

The  research  directors'  staffs  perform  many  additional 
"information  handling"  tasks.  These  tasks  include  the  maintenance  of 
detailed  records  concerning  research  completion  status,  formal 
publication  information,  thesis  advisor  qualifications,  and  sponsorship 
statistics .  Each  school  currently  employs  a  number  of  manual  and 
automated  record-keeping  systems  to  accomplish  these  functions;  however, 
none  offers  a  well -structured,  integrated  view  of  the  information 
available  within  the  respective  research  programs .  In  recognition  of 
this  fact,  the  DE  and  LS  research  directors  strongly  supported  this 
study's  goal  of  building  a  prototype  system  for  integrating  the  varied 
sources  of  research  information.  They  further  stated  that  the  system 
could  greatly  aid  the  conduct  and  management  of  their  school's  programs 
(Duncan,  1991;  Emmelhainz,  1991a) . 

Diftgrgntgs  Angng  School  Research  Programs .  Personal 
interviews  with  the  research  directors  revealed  few  significant 
differences  among  the  three  schools'  research  programs.  The  most 
important  difference  concerned  the  opposing  philosophies  that  exist  on 
thesis  topic  selection  by  students.  In  DE  and  LS,  students  may  develop 
their  own  topics  or  select  them  from  other  sources  (Duncan,  1991; 
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Emmelhainz ,  1991a).  EN  students  are  required  to  complete  their  theses 
on  funded,  sponsored,  or  continuing  research  topics.  As  a  result,  very 
few  student-derived  topics  have  been  approved  over  the  last  several 
years  (Bridgman,  1991) . 

The  differing  philosophies  on  thesis  topic  selection  have  yielded 
somewhat  predictable  results  in  the  area  of  continuing  studies .  DE  and 
LS  have  conducted  relatively  few  recent  continuing  studies  (Duncan, 

1991;  Emmelhainz,  1991a),  while  EN  has  a  long  history  of  performing  such 
studies  (Bridgman,  1991) .  The  DE  and  LS  research  directors  both 
indicated  that  an  increase  in  continuing  studies  could  be  realized  if 
incoming  students  had  an  improved  method  for  accessing  information  about 
previously  completed  and  ongoing  research  studies  (Duncan,  1991; 
Emmelhainz,  1991a).  At  the  suggestion  of  these  directors,  the 
requirement  for  this  capability  was  added  to  the  prototype  ARMS 
functional  description. 

Research  Support  Facilities.  The  overall  AFIT  research 
program  is  supported  by  a  variety  of  campus  and  Wright -Patterson  Air 
Force  Base  facilities.  A  major  campus  resource  is  the  academic  library, 
which  provides  a  host  of  useful  services.  The  library's  current 
collections  include  over  85,000  books,  1,350  science  and  management 
journals,  and  850,000  government -sponsored  technical  reports.  These 
resources  are  augmented  by  a  large  audiovisual  materials  library  and 
many  computerized  catalog  systems.  The  automated  support  encompasses  a 
number  of  major  systems,  such  as  those  managed  by  the  Defense  Technical 
Information  Center  (DTIC),  National  Aeronautics  and  Space  Administration 
(NASA) ,  DIALOG  Informational  Service,  and  On-line  Computer  Library 
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Center  (OCLC) .  In  addition  to  its  material  resources,  the  library  has  a 
trained  reference  staff  to  assist  researchers  with  bibliographic 
searches  and  other  library- oriented  services  (AFIT,  1990:IX-2  -  IX-4). 

The  AFIT  campus  is  further  complemented  by  a  series  of  specialized 
research  laboratories  and  an  extensive  network  of  computer  systems . 
Modern  laboratories  are  available  to  support  the  following  EN 
disciplines:  Aeronautics  and  Astronautics;  Electrical  and  Computer 
Engineering;  Navigation,  Guidance,  and  Control;  Robotics  Systems;  and 
Engineering  Physics  (AFIT,  1990;IX-7  -  IX-12).  Each  school  also 
maintains  several  computer  laboratories  that  provide  access  to  general 
purpose  (word  processing,  database,  communications)  and  specialized 
software  applications  (AFIT,  1990:IX-14). 

AFIT's  geographic  location  at  Wright- Patterson  Air  Force  Base,  one 
of  the  Air  Force's  leading  research  and  development  facilities,  provides 
researchers  with  access  to  numerous  additional  resources  (AFIT,  1990; IX- 
7 ) .  The  tenth  edition  of  the  Directory  Libraries  and  Information 
Centers  ^  Wright- Patterson  Ain  Force  Base,  published  by  the  Wright 
Research  and  Development  Center  (WRDC) ,  describes  twenty-two  major 
sources  of  information  and  reference  material  (Wright  Research  and 
Development  Center,  1990) .  The  base  is  also  home  to  several  research, 
development,  test  and  evaluation  laboratories,  and  a  number  of  key 
procurement  and  materiel  management  agencies,  such  as  the  Air  Force 
Materiel  Command  headquarters.  Aeronautical  Systems  Center,  and  Foreign 
Aerospace  Systems  Technology  Center  (AFIT,  1990:IX-7). 
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JLS  Student  Research  Program.  The  LS  student  research  program  is 
governed  by  LS  Operating  Instruction  (LSOI)  50-3,  "Thesis  Research 
Program."  According  to  this  document,  the  program's  goals  are  to; 

a.  provide  students  the  opportunity  to  gain  experience  in  problem 
analysis,  independent  research,  and  written  expression; 

b.  enhance  student  knowledge  in  one  of  six  specialized  areas; 
Logistics  Management,  Systems  Management,  Information  Systems 
Management,  Cost  Analysis,  Contracting  Management,  or  Software 
Systems  Management;  and 

c.  identify  military  management  problems  and  contribute  to  the 
solution  of  those  problems.  (LSOI  50-3,  1992 ;1) 

Process -Oriented  Focus .  In  line  with  this  guidance,  LS 
student  theses  are  viewed  as  more  than  just  a  product .  According  to  the 
LS  research  director,  careful  consideration  and  evaluation  of  the 
process  used  to  derive  and  document  results  are  essential  aspects  of 
conducting  a  quality  research  program.  Figure  2-1  contains  a  general 
research  process  model  that  is  presented  to  each  incoming  class  of  LS 
students  in  a  thesis  overview  briefing  by  the  LS  research  director.  The 
model  is  intended  to  serve  as  a  guide  for  new  students;  although  it  may 
require  modification  for  use  in  specific  studies  (Emmelhainz,  1991c). 

General  Research  Process  Model 

1 .  Select,  define,  and  scope  the  problem. 

2.  Develop  a  concept  map  or  organization  chart. 

3.  Collect  or  create  data. 

4.  Analyze  data  and  determine  problem  solution. 

5.  Arrange  material  for  report. 

6.  Produce  the  report  (thesis  text). 

Figure  2-1.  General  Research  Process  Model  (Emmelhainz,  1991) 
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Schedule .  The  LS  student  research  program  has  a  set  of 
established  milestones  that  guides  students  through  the  thesis  process . 
Figure  2-2  shows  the  approximate  schedule  of  major  student  research 
activities  for  the  1992  academic  year.  This  schedule  was  generally 
applicable  to  most  degree  programs;  however,  some  students  completed 
COMM  687  and  COMM  630  one  academic  quarter  later  than  the  indicated 
timeframe  (LSOI  50-1,  1991).  In  addition,  the  Figure  2-2  example  is 
normally  supplemented  by  a  more  detailed,  student -generated  schedule 
that  covers  the  execution  of  the  specific  thesis  methodology  and  forms 
the  basis  for  the  agreement  between  the  thesis  committee  and  student 
team  members  (LSOI  50-3,  1992:2). 

Responsibilities .  Several  people  share  responsibilities 
with  students  to  assure  the  qualitative  completion  of  theses.  These 
individuals  include  personnel  from  the  research  director’s  staff  (which 
is  formally  referred  to  as  the  Office  of  Research  and  Consulting),  the 
degree  program/option  manager,  and  the  thesis  committee  advisors .  LSOI 

50-3  describes  their  specific  responsibilities  as  follows: 

a.  The  Office  of  Research  and  Consulting  (LSC)  wil] : 

(1)  Administer  and  supervise  the  thesis  research  program. 

(2)  Collect  potential  research  topics. 

(3)  Coordinate  faculty  review  and  screening  of  topics. 

(4)  Prepare  faculty-approved  topics  for  student  review. 

(5)  Maintain  a  list  of  potential  advisors  with  research 
interests  and  qualifications . 

(6)  Monitor  selection  of  committee  advisors  for  student 
teams . 

(7)  Prescribe  format  and  administrative  requirements  for 
preparation  of  the  final  copy  of  the  thesis. 

(8)  Review  the  final  copy  of  the  thesis  to  ensure  compliance 
with  the  prescribed  format. 

(9)  Supervise  the  publication  and  distribution  of  tlieses 

b.  Program/Option  Managers  will: 

(1)  Collect  potential  research  topics  related  to  their 
program/option . 
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nal  Appi'oval  Date 


(2)  Assure  that  students  in  the  program/option  select 
appropriate  topics  and  form  committees  by  1  Nov. 

(3)  Monitor  thesis  progress  of  students  in  their 
program/option . 

c .  Committee  Advisors  will : 

(1)  Assist  Students  in  limiting  and  focusing  topics  to  a 
resea rchable  problem. 

(2)  Approve/disapprove  the  thesis  proposal  produced  in  COMM 
630  . 

( 3 )  Appoint  one  committee  advisor  as  administrator  to  help 
the  students  schedule  meetings  and  to  facilitate 
administrative  requirements . 

(4)  Review  student  travel  requests  and  recommend  approval  to 
AFIT/LSG . 

(5)  Approve/disapprove  data-gathering  instruments  and  forward 
to  AFIT/XPX  for  processing. 

(6)  Read,  evaluate,  and  comment  on  student  drafts  and  provide 
prompt  feedback. 

(7)  Report  thesis  grades  to  LSC  at  each  grading  period 
specified  in  the  student's  education  plan. 

(8)  Judge  acceptability  of  content,  organization,  technical 
quality,  and  expression  of  thesis. 

(9)  Approve  the  final  draft  for  publication  in  accordance 
with  AFR  190-1,  AU  Sup  1,  and  pertinent  DoD  directives. 

(10)  Select  the  appropriate  distribution  option  from  the  AFIT 
stylg  Guidg  lor  Theses  and  Dissertations .  (LSOI  50-3, 
1992:2-4) 

The  LSC  responsibilities  listed  above  represent  the  research 
director's  "internal"  responsibilities  mentioned  earlier  in  this 
section.  They  are  administrative  in  nature  and  depict  the  research 
director's  role  as  a  "facilitator"  of  the  process  (Emmelhainz,  1991b). 

Absent  from  the  above  list  are  the  students'  responsibilities.  In 
a  general  sense,  there  are  four:  select  a  thesis  partner,  select  a 
topic,  select  committee  advisors,  and  do  the  work  (Emmelhainz,  1991c; 
LSOI  50-3,  1992:2).  However,  the  detailed  execution  of  these 


responsibilities  is  an  extensive  effort  and  prone  to  the  types  of 
difficulties  discussed  later  in  this  section. 

Quality  and  Awards .  The  qualitative  evaluation  of  a  thesis' 
written  expression  and  final  format  is  incumbent  on  the  committee 
advisors  and  LSC,  respectively.  According  to  the  LS  research  director, 
thesis  committee  advisors  are  encouraged  to  stress  quality  throughout 
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Figure  2-3.  Thesis  Evaluation  Criteria  (Eitimelhainz,  1991) 


the  research  process.  Figure  2-3  provides  advisors  with  sample  criteria 
on  which  to  base  their  assessment  of  a  project.  While  these  criteria 
are  considered  comprehensive,  advisors  may  use  their  own  judgment  on  how 
to  evaluate  student  theses  and  assign  grades  ( Emmelhainz ,  1991a)  . 

The  thesis  awards  program  is  conducted  under  the  auspices  of  LSOI 
53-3,  "Awards  and  Special  Recognition  for  Students  in  Master  of  Science 
Degree  Programs."  This  document  describes  four  thesis  awards  that  may 
be  presented  to  LS  students:  the  AFIT  Commandant's  Award,  Dr,  Leslie  M. 
Norton  Pride  in  Excellence  Award,  National  Estimating  Society  Award,  and 
National  Contract  Management  Association  Award.  The  first  two  awards 
are  given  to  recognize  exceptional  contributions  and  outstanding 
quality;  while  the  latter  two  honor  exceptional  studies  in  specific 
disciplines.  To  receive  one  or  more  of  these  awards,  a  thesis  must  be 
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nominated  by  the  study's  advisors,  recommended  by  the  appropriate  awards 
committee,  and  approved  by  a  faculty  vote  (LSOI  53-3). 

Student  Researcher  Difficulties .  The  student  researcher 
potentially  faces  many  difficulties  in  conducting  a  thesis  or 
dissertation  project.  This  review  focuses  on  some  of  the  more  prevalent 
issues  described  in  the  literature,  which  can  be  grouped  into  the 
following  categories:  understanding  research,  managing  time,  selecting  a 
topic,  and  locating  and  reusing  available  resources.  Each  of  these 
categories  is  discussed  below  in  terms  of  their  attributes  and  context 
within  the  AFIT  LS  research  environment. 

Understanding  Research .  One  source  of  difficulty  for 
graduate  students  stems  from  their  "lack  of  experience  in  thinking  about 
problems  as  subjects  for  rigorous,  systematic  study"  (Evans,  1991:3). 

The  students'  understanding  of  research  may  be  further  clouded  by  the 
many  diverse  meanings  of  research  and  the  requirements  each  discipline 
employs  for  determining  what  constitutes  an  acceptable  thesis  project. 
Some  key  differences  include  the  informal  and  formal  expectations  about 
data  collection  and  analysis  technique  use,  sampling  quantification, 
measurement  precision,  and  report  length  (Allen,  1973:3). 

Despite  these  differences,  student  researchers  can  increase  their 
chances  for  success  by  considering  research  as  a  process  with  steps 
leading  from  initiation  to  completion.  It  is  equally  important  for  them 
to  approach  the  process  in  a  proactive  manner  by  anticipating  and 
planning  to  minimize,  or  avoid,  potential  problems.  Failure  to  do  so 
could  jeopardize  the  successful  completion  of  their  study  (Allen, 

1973 : vii-viii) . 
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To  provide  student  researchers  with  an  understanding  of  research, 
all  LS  graduate  programs  require  the  completion  of  two  courses,  Theory 
and  Practice  of  Professional  Communication  (COMM  687)  and  Research 
Methods  (COMM  630).  COMM  687  instructs  students  on  the  areas  of  written 
and  oral  communication  skills  and  introduces  the  AFTT  Style  Guide  for 
Theses  and  Dissertations  (Stibravy,  1991:2).  This  course  also  requires 
each  student  to  complete  a  ten-  to  twelve-page  literature  review  on  a 
topic  of  the  student's  choosing,  but  preferably  the  student's  thesis 
topic  (Stibravy,  1991:2).  COMM  630  provides  students  with  an 
"understanding  of  basic  research  methods  and  concepts  related  to 
scientific  inquiry"  (Huguley,  1991:2).  By  the  end  of  this  course,  each 
student  or  student  team  must  complete  a  research  proposal  containing 
drafts  of  the  first  three  thesis  chapters  (Huguley,  1991:2). 

Managing  Time .  Time  is  an  interesting  and  paradoxical 
aspect  of  the  research  process.  While  it  is  logical  to  expect  quality 
research  to  require  a  significant  amount  of  time  and  effort,  spending 
too  much  time  on  a  project  can  be  counterproductive  (Allen,  1973 :vii; 
Madsen,  1983:21).  In  fact,  many  projects  are  extended  by  factors  chat 
"do  not  increase  the  quality  of  the  final  report  or  teach  the  student 
anything  worthwhile  about  academic  research"  (Allen,  1973:vii).  These 
factors  include  faculty  (advisor)  mobility  and  changes  in  the  problem 
environment  that  impede  the  completion  or  negate  the  need  for  a  study 
(Madsen,  1983:21). 

Although  the  student  researcher  has  little  control  over  many 
delay- causing  factors,  "proper  planning  before  research  is  started  can 
significantly  reduce  the  time  required  to  produce  high  quality  results" 
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(Allen,  1973 :vii).  Students  should  begin  looking  for  a  research  topic 
soon  after  beginning  their  graduate  work,  as  long  as  their  selection  is 
not  made  too  hastily  (Allen,  1973:14).  By  finding  suitable  topics 
early,  students  can  select  and  optimally  benefit  from  courses  that 
increase  their  knowledge  of  the  research  project  (Madsen,  1983:21). 

Some  aspects  of  the  current  LS  research  environment  inhibit  the 
early  planning  efforts  of  incoming  research  students.  First,  new 
students  arrive  at  AFIT  in  May  during  the  middle  of  the  current 
students'  research  efforts.  This  significantly  limits  their  access  to 
both  current  researchers  and  advisors  until  early  September,  which  is 
just  after  the  thesis  approval  deadline  date  for  graduating  students. 
While  new  students  can  continue  to  research  potential  topics,  they  are 
delayed  from  obtaining  valuable  advisor  feedback  on  new  topics  or 
information  about  ongoing  research  studies.  The  inability  to  hone  in  on 
a  topic  early  can  lead  many  students  taking  COMM  687  during  the  summer 
term  (July -September)  to  complete  their  required  literature  review 
assignments  on  areas  unrelated  to  their  eventual  theses.  Students  still 
learn  about  research  when  this  occurs,  but  they  are  unable  to  optimally 
use  their  effort  and  time  (Emmelhainz,  1991b) . 

Selecting  4  Research  Topic .  The  literature  indicates  a 
plethora  of  research  topics  exists  (Allen,  1973:11;  Madsen,  1983:21). 
However,  the  selection  and  refinement  of  a  topic  that  fulfills  a 
department's  unique  criteria  for  contributing  to  a  discipline's  body  of 
knowledge  are  still  very  difficult  tasks  (Allen,  1973:12),  There  are  a 
number  of  recommended  sources  for  research  topics,  some  of  which 
include:  recently  completed  theses,  professional  journals,  student 
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associations  or  other  local  groups,  research  librarians,  course 
lectures,  published  abstracts,  and  thesis  and  dissertation  defenses 
(Allen,  1973; 18;  Madsen,  1983:21). 

Theses  and  professional  journals  are  especially  beneficial  if 
certain  procedures  are  followed.  When  reviewing  recently  completed 
theses,  researchers  should  consider  the  further  research  recommendations 
listed  in  award-winning,  or  other  faculty- suggested  reports.  In 
conducting  journal  reviews,  special  attention  should  be  given  to  lists 
of  recently  completed  and  ongoing  dissertations  or  other  research 
projects.  These  sources  not  only  giv'e  student  researchers  insight  into 
what  other  scholars  think  is  important,  but  they  also  provide  them  with 
a  valuable  list  of  potential  contacts  (Madsen,  1983:21). 

Similar  to  the  diverse  number  and  nature  of  sources  for  topics, 
there  exists  a  wide  range  of  criteria  that  can  be  used  for  selecting  and 
refining  a  research  topic.  A  "good"  topic  should: 

1)  be  of  current  or  future  interest; 

2)  be  narrow  and  specific  (instead  of  broad  and  nebulous); 

3)  be  of  interest  to,  and  in  the  knowledge  area  of,  the  selected 
faculty  advisors; 

4)  be  accessible  (data  is  obtainable  or  available), 

5)  sustain  interest  and  stimulate  the  researcher's  imagination; 

6)  be  within  the  researcher's  range  of  competence; 

7)  permit  the  researcher  to  demonstrate  independent  mastery  of 
both  the  subject  and  the  appropriate  research  method;  and 

8)  have  the  potential  to  make  an  original  contribution  to  the  sum 
of  human  knowledge.  (Allen,  1973:12,  Madsen  1983:23) 
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while  each  of  the  items  on  the  above  list  are  important,  it  is  the 
last  one  that  most  often  impacts  the  student's  ability  to  decide  on  a 
research  topic.  It  is  particularly  difficult  for  students  learning  the 
art  of  research  to  determine  the  potential  "contribution"  of  a  project 
since  a  formal  policy  rarely  exists  at  their  university.  One  viev  in 
the  literature  suggests  that  the  circulation  of  any  topic  widely  enough 
will  garner  a  full  range  of  opinions.  To  be  successful,  the  student 
researcher  must  wisely  consider  this  factor  in  the  process  of  selecting 
a  topic  (Allen,  1973:13). 

The  LS  research  environment  provides  students  with  several 
resources  for  locating  topics.  As  discussed  earlier,  some  of  the 
resources  are  automated  systems.  However,  none  of  the  systems 
identifies  past  or  ongoing  in-house  research  studies  that  merit  further 
or  cross-sectional  study.  Such  topics  are  either  informally  passed  on 
to  incoming  LS  students,  forgotten,  or  discovered  incidentally 
(Emmelhainz,  1991a). 

In  addition  to  the  options  of  "reviving"  a  previously  completed 
study  or  continuing  an  ongoing  study,  LS  student  researchers  may 
personally  generate  a  topic  or  select  one  from  the  Thesis  Topic  Book 
maintained  by  the  Thesis  Program  Administrator.  The  latter  option 
involves  manually  searching  through  ordered  groupings  of  new  research 
requests  that  have  been  received  from  two  major  sources:  1)  DoD 
organizations,  as  a  result  of  the  annual  "call  for  thesis  topics";  and 
2)  AFIT  faculty  members,  who  derive  topics  from  their  consulting 
responsibilities.  Although  this  tool  exists,  its  utility  (in 
statistical  or  other  terms)  is  unsubstantiated  (Emmelhainz,  1991a) 
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During  the  interviews  conducted  with  the  LS  and  DE  research 


directors,  the  requirement  for  an  automated  system  to  replace  the 
current  Thesis  Topic  Book  was  expressed.  Besides  its  replacement  role, 
the  new  system  should  have  the  ability  to  provide  researchers  with 
pertinent  information  on  past  and  ongoing  research  efforts.  It  was  also 
recommended  that  the  system  be  capable  of  providing  management  with 
feedback  on  its  utility.  The  requirements  gathered  during  these 
interviews  were  incorporated  into  the  ARMS  functional  description  and 
formed  the  basis  of  the  Research  Topic  Selection  Subsystem  (RTSS) 

(Duncan,  1991;  Emmelhainz,  1991a). 

Locating  and  Reusing  Resources .  One  characteristic  of  a 
good  research  study  is  that  its  results  are  verifiable  (Emory  and 
Cooper,  1991:15).  Consequently,  a  completed  research  project 
customarily  yields  a  report  that  not  only  documents  results,  but 
contains  details  about  the  methodology  and  tools  (surveys, 
questionnaires,  statistic  analysis  models)  employed  during  the  study 
(Emory  and  Cooper,  1991:15-16,  374-375).  Research  studies  may  also 
yield  output  products,  such  as  prototype  system  designs,  computer 
software  programs,  or  guidebooks.  While  these  "components"  are  often 
well -documented  in  their  respective  theses,  they  are  archived  without 
consideration  of  their  potential  for  further  use,  or  the  role  the',-  could 
play  in  promoting  continuing  studies  (Duncan,  1991;  Emmelhainz,  1991a). 
More  detailed  information  about  the  potential  benefits  and  pitfalls  of 
reuse  are  described  in  the  next  section. 
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Reuse 


Research  is  performed  in  many  ways,  but  the  common  thread 
throughout  all  research  is  the  need  for  information.  Maurice  Glicksman, 
in  his  address  to  the  Conference  on  Information  Resources  for  the  Campus 
of  the  Future,  discusses  the  goals  of  higher  education.  Glicksman 
explains  that  one  goal  is  the  "conservation  of  knowledge"  (Glicksman, 
1987:26)  because  "without  the  conservation  process,  we  would  go  through 
a  new  learning  process  every  generation.  This  would  be  highly 
inefficient  for  society"  (Glicksman,  1987:30).  Edgar  Bright  VJilson,  Jr. 
further  states: 

Science  by  its  very  nature  is  a  structure  which  grows  by  the 
addition  of  new  material  on  top  of  a  great  edifice  formed  by 
earlier  workers .  An  individual  completely  ignorant  of  what 
was  known  before  has  little  chance  of  making  a  worthwhile 
new  contribution.  Consequently,  before  beginning  a  new 
research  project  it  is  essential  to  find  out  the  existing 
state  of  the  field.  (Wilson,  1952:10) 

Therefore,  in  order  for  a  research  product  to  be  successful,  the 

researcher  must  be  aware  of  the  current  state  of  kno- fledge  and  be  able 

to  reuse  it. 

Knowledge  Reuse .  Knowledge  reuse  is  dependent  upon  researchers 
passing  on  knowledge  which  they  have  added  to  the  field.  Researchers 
are  able  to  pass  the  knowledge  to  their  colleagues  directly  or 
indirectly.  Direct  communication  among  researchers  allows  interaction 
to  ensure  the  information  is  transferred  correctly.  Indirect 
communication  occurs  through  journals  and  published  papers  but  does  not 
allow  interaction  (Glicksman,  1987:30).  The  computer  has  been 
introduced  to  enhance  both  direct  and  indirect  knowledge  reuse  (Markoff, 


Networks  of  computers  provide  researchers  the  ability  to 
communicate  with  one  another  anywhere  in  the  world.  One  such  network  is 
the  Internet.  The  Internet  was  created  in  the  1960s  by  the  Defense 
Advanced  Projects  Research  Agency  as  a  means  to  improve  communication 
between  researchers  (Markoff,  1991:49).  Additionally,  in  order  to 
improve  the  United  States'  international  standing  in  technology,  the 
Congress  has  been  debating  the  creation  of  a  National  Research  and 
Education  Network  (NREN)  which  will  enhance  research  by  providing 
quicker  transfer  of  information  throughout  the  network  (Fisher, 

1991; 182) . 

Computers  can  also  store  knowledge  for  researchers  to  access  at  a 
later  time.  In  fact  '  -  Congressional  Office  of  Technology  Assessment 
found  in  1990  thaw  ^formation  gained  through  government  funding  sliould 
be  stored  in  computerized  databases  to  improve  private  companies ’  access 
to  this  information  (Markoff,  1990:2). 

Even  with  the  increased  importance  of  improving  knowledge  reuse, 
the  greatest  strides  currently  being  made  in  the  area  of  reuse  are 
occurring  in  software  development.  The  following  examination  of 
software  reuse  provides  the  basis  for  the  authors'  discussion  of 
knowledge  reuse . 

Software  Reuse .  Ruben  Pritco-Diaz  and  Peter  Freeman  in  their 
paper,  "Classifying  Software  for  Reusability,"  state  that  the  concept  of 
software  reuse  has  been  studied  for  almost  25  years  (Prieto-Diaz  and 
Freeman,  1987:6).  The  main  thrust  of  research  on  this  topic  is  related 
to  the  classification  and  retrieval  of  software  components . 
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Benefits .  The  employment  of  software  reuse  can  benefit  the 
software  process  in  four  main  areas:  programmers  can  increase  their 
productivity  by  developing  less  new  software  and  depending  more  on 
reusable  software  (Margono  and  Berard,  1987:63;  Coomer  and  others, 
1990:34);  software  products  are  more  reliable  because  they  have  already 
been  tested  (Margono  and  Berard,  1987:63);  total  software  costs  are 
decreased  because  reused  software  components  do  not  have  to  be 
redesigned,  redeveloped,  or  retested  (Margono  and  Berard,  1987:63, 

Dusink  and  van  Kalwiyk,  1987:114);  and  the  software  products  have 
expanded  uniformity  and  quality  because  the  components  are  retrieved 
from  a  standard  set  of  software  components  (Margono  and  Berard, 

1987:63)  . 

Successes .  Raytheon  implemented  software  reuse  in  the  late 
1970s,  and  within  three  years,  showed  a  great  improvement  in 
productivity.  During  this  period,  forty  to  sixty  percent  of  the 
software  in  Raytheon  applications  was  reused  from  previous  programs. 

The  practice  of  software  reuse  now  has  Raytheon's  programmers  producing 
software  up  to  forty  times  faster  with  better  quality,  and  higher 
maintainability  characteristics.  In  addition,  Raytheon's  trainees  are 
more  productive  after  only  three  months  of  training  than  some 
experienced  programmers  who  do  not  reuse  software  (Lanergan  and  Poynton, 
1979:127-128) . 

Toshiba  has  increased  productivity  by  eight  to  nine  percent  each 
year  in  the  Fuchu  Software  Factory  since  1977  by  reusing  code  during 
software  development.  During  this  same  time,  Fuchu  has  maintained  a  low 
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number  of  faults  per  thousand  lines  of  code  (Coomer  and  others, 

1990  :  37)  . 

NASA  carried  out  a  series  of  projects  to  determine  the  advantages 
of  reusing  software.  By  the  end  of  the  third  project,  reusable  software 
accounted  for  forty  percent  of  the  total  project,  productivity  increased 
by  over  fifty  percent,  and  the  number  of  errors  decreased  by  over 
seventy  percent  (McGarry,  1989:57-58). 

McDonnell  Douglas  performed  a  study  on  the  missile  packages  they 
were  developing  for  the  Department  of  Defense  to  determine  if  softv.-are 
reuse  could  be  employed  effectively.  McDonnell  Douglas  found  that  its 
missile  software  system  contained  over  200  reusable  components.  The 
researchers  also  determined  that  a  software  component  which  almost 
satisfied  a  requirement  could  be  modified  easier  than  developing  a  new 
component  (McNicholl  and  others,  1986:104,106). 

Computer  Sciences  Corporation  developed  guidelines  for  writing 
mission  critical  computer  resource  software  based  on  reusable  components 
(Gargaro  and  Pappas,  1987:51).  Gargaro  and  Pappas  state  that,  in  order 
for  software  reuse  to  be  effective,  reuse  must  be  considered  throughout 
both  the  design  and  implementation  phases  (Gargaro  and  Pappas,  1987:43). 

IBM  introduced  the  concept  of  software  building  blocks  which  can 
be  reused  by  their  programmers  to  design  and  build  new  systems  (Lenz, 
Schmid  and  Wolf,  1987:34).  This  concept  was  tested  with  NASA,  and  the 
results  showed  that  the  projects  on  which  building  blocks  were  used  had 
ten  to  twenty- five  percent  reused  software  and  produced  better  quality 
products  (Lenz,  Schmid  and  Wolf,  1987:42;  Baida  and  Gustafson,  1990:42). 
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Drawbacks .  Even  with  all  of  the  successes,  some  firms  are 
wary  of  instituting  a  reuse  process  within  their  organization. 
Biggerstaff  and  Richter  catalog  this  concern  into  two  areas:  dilemmas 
and  inhibiting  factors  (Biggerstaff  and  Richter,  1987:42-45). 

A  dilemma  occurs  when  a  positive  gain  in  one  area  causes  a 
negative  gain  in  a  second  area.  Biggerstaff  and  Richter's  first  dilemma 
addresses  the  fact  that  a  software  component  will  get  reused  more  if  it 
performs  a  general  function.  However,  as  a  component's  function  becomes 
more  general,  the  component  must  be  modified  in  order  to  be  effective  in 
a  specific  application.  The  second  dilemma  deals  with  the  size  of  the 
component.  As  a  component  gets  larger,  it  becomes  more  effective 
because  it  performs  a  more  specific  function.  On  the  other  hand,  as  a 
component  grows  larger,  its  complexity  increases  as  well  as  its 
maintenance  cost.  The  final  dilemma  is  that  although  a  library  is 
necessary  to  effectively  reuse  software  components,  the  cost  of  creating 
this  library  is  very  high  (Biggerstaff  and  Richter,  1987:42-43). 

The  inhibiting  factors  center  on  the  people  of  an  organization. 
First,  programmers  do  not  have  a  standard  method  of  designing  software 
that  encourages  reuse.  Second,  management  normally  does  not  provide  a 
clear  strategy  for  developing  a  reuse  policy.  Third,  programmers  are 
often  unwilling  to  accept  other  programmers'  work  because  the  software 
may  have  problems  which  must  be  solved  before  it  can  be  reused.  This  is 
commonly  called  the  "not- invented- here"  (NIH)  syndrome.  Finally, 
managers  do  not  want  to  expend  the  capital  required  to  institute  a  reuse 
program  (Biggerstaff  and  Richter,  1987:45). 
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other  drawbacks  include  the  fact  that  all  programmers  do  not  use  a 


standard  language,  and  project  managers  have  very  little,  if  any, 
training  in  the  principles  of  software  engineering  (Coomer  and  others, 
1990:33).  Additionally,  programmers  could  potentially  develop  a 
software  module,  using  reused  components,  which  is  too  specific  to  be 
reused  itself.  This  would  violate  the  principle  that  a  software  process 
should  produce  components  which  can  be  reused  in  future  projects  as  well 
as  reuse  components  from  previous  projects  (Welch,  1987:86).  Finally, 
the  task  of  cataloging  the  components  for  reuse  could  be  so  difficult 
that  any  benefits  gained  would  be  overcome  (Horowitz  and  Munson, 

1984 :481>  . 

Sample  Reuse  Process .  Prieto-Diaz  states  that  a  software 
reuse  program  must  be  structured  and  addressed  systematically  (Prieto- 
Diaz,  1991:62).  In  order  for  software  to  be  reused,  it  must  first  be 
stored  in  a  central  location,  called  a  software  library  (Burton  and 
others,  1987:41).  The  software  components  stored  in  this  library  must 
be  well-defined,  useful  in  a  number  of  different  situations,  and  of 
proven  high  quality  (Coomer  and  others,  1990:34-35).  The  software 
should  also  be  cataloged  to  help  distinguish  one  component  from  another 
(Prieto-Diaz  and  Freeman,  1987:7).  To  further  enhance  its  reusability, 
the  software  could  be  cataloged  in  many  ways  to  anticipate  all  of  its 
possible  uses  (Mac  An  Airchinnigh,  1984:70). 

Once  the  software  has  been  cataloged  and  stored  in  the  library, 
programmers  can  query  an  automated  retrieval  system  for  reusable 
components  to  use  in  current  projects.  The  retrieval  system,  which  is 
normally  an  information  system,  will  take  the  specified  software 
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requirements,  examine  the  library,  and  provide  a  candidate  list  of  all 
components  which  meet  those  requirements.  The  retrieval  system  also 
provides  information  about  each  component.  Based  upon  this  information, 
the  programmer  can  select  a  component  which  will  be  the  easiest  to  reuse 
( Prieto-Diaz,  1987:6-7). 

Domain  Analysis .  The  first  step  in  developing  a  reuse 
program  should  be  a  domain  analysis  (Holibaugh,  1989:267).  The  goal  of 
a  domain  analysis  is  to  describe  the  problems  within  the  domain  along 
with  the  software  which  solves  these  problems.  This  goal  is  achieved 
through  the  development  of  a  domain  model  and  software  architecture. 

The  domain  model  represents  a  picture  of  the  domain  while  the  software 
architecture  describes  the  software  currently  available  within  the 
domain  (Holibaugh,  1989:274). 

Advantages .  One  advantage  of  a  domain  analysis  is 
that  it  will  capture  expertise  from  an  organization  which  can  be 
tailored  for  use  in  a  specific  area.  This  expertise  can  identify  common 
problems  of  past  systems  and  develop  methods  of  solving  these  problems . 
These  solutions  can  then  be  applied  to  similar  problems  which  arise  in 
new  systems.  Also,  knowledge  from  past  systems  can  be  used  as  a 
training  aid  for  new  employees  (Holibaugh,  1989:267). 

Disadvantages .  The  main  disadvantage  of  domain 
analysis  is  in  the  area  of  assessment.  benefits  gained  from  a 

domain  analysis  cannot  be  fully  measured  until  the  new  system  has  been 
implemented.  Once  the  system  is  active,  the  productivity  and 
reliability  can  be  compared  to  previous  results  to  determine  if  the 
domain  analysis  was  successful.  Other  disadvantages  of  domain  analysis 
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are  the  lack  of  guidance  for  performing  the  analysis  and  the  shortage  of 
domain  experts  who  supply  the  information  to  the  domain  analysts 
(Holibaugh,  1989:267). 

Approach .  Within  the  software  environment,  when  a 
reusable  component  is  required,  the  software  architecture  is  examined  to 
determine  if  software  with  similar  functionality  is  available  within  the 
domain.  The  common  traits  from  the  existing  components  are  identified 
and  then  reused  in  the  development  of  the  new  component.  If  no  similar 
component  exists,  efforts  are  made  to  determine  if  the  new  component 
should  be  developed  for  just  the  current  project,  or  if  it  should  l.e 
developed  in  a  way  to  make  it  reusable  for  future  projects  as  well 
(Baida  and  Gustafson,  1987:42-43). 

Once  the  domain  analysis  has  been  performed,  it  is  imperative  that 
the  domain  model  and  software  architecture  are  updated  regularly.  For 
every  new  development,  the  domain  must  be  analyzed  to  identify  any 
necessary  changes.  Some  possible  changes  could  be  the  addition  of  new 
software  components  or  the  removal  of  outdated  components  (Holibaug.h, 
1989:275-276;  Prieto-Diaz,  1987:28). 

Successes .  As  stated  earlier,  the  success  of  a  domain 
analysis  cannot  be  determined  until  the  system  has  been  developed  and 
tested  (Holibaugh,  1989:267).  Some  organizations  have  already  had  an 
opportunity  to  validate  the  success  of  using  the  domain  analysis 
technique.  The  recent  software  development  successes  of  both  Raytheon 
and  McDonnell  Douglas,  as  discussed  earlier  in  this  cliapter,  have  been 
directly  attributed  to  the  performance  of  a  domain  analysis  prior  to 
initiating  their  reuse  programs  (Prieto-Diaz,  1987:23;  25-26). 
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Applicability  this  Study .  The  authors'  intent  is 


to  develop  a  domain  model  and  software  architecture  that  will  enhance 
knowledge  reuse  within  LS .  The  particular  technique  for  this  model  is 
the  entity  relationship  diagram  (ERD)  (Holibaugh,  1989:274).  The  ERD 
for  the  ARMS  "knowledge  domain"  is  described  more  fully  in  the  design 
portion  of  Appendix  K.  The  software  architecture  is  comprised  of  the 
proposed  AFIT  Research  Management  System  and  the  research  facilities 
listed  earlier  in  this  chapter. 

Current  Research .  Current  reuse  research  is  addressing  more 
of  the  nontechnical  issues  related  to  software  reuse:  managerial, 
economic,  legal,  cultural,  and  social.  Researchers  have  realized  that 
the  nontechnical  issues  form  the  foundation  of  a  successful  reuse 
program  ( Prieto-Diaz ,  1991:61). 

Information  Systems 

An  information  system  is  "an  organized  way  to  effect  information 
transfer  within  a  specific  field"  (Weisman,  1972:14).  Information 
systems  are  able  to  maintain  data  for  future  use  and  process  data  to 
produce  information  and  reports  (Senn,  1984:15).  Many  times  an 
information  system  does  not  allow  the  extraction  of  the  information 
pertinent  to  the  current  project.  After  retrieving  the  information, 
further  processing  is  required  of  the  researcher  to  remove  the 
unessential  information  (Tsichritzis  and  Lochovsky,  1977:26).  A  data 
base  management  system  (DBMS)  is  a  computerized  form  of  information 
system  which  provides  a  more  flexible  interface  between  the  researcher 
and  the  information  (Senn,  1984:370-1).  For  the  purpose  of  this  thesis. 
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the  terms  information  system  and  DBMS  are  used  synonymously  to  refer  to 
a  computerized  system. 

Data  Base  Management  .System  Concepts  .  The  smallest  unit  of  data 
within  a  DBMS  is  called  a  data  item,  and  a  collection  of  data  items 
comprises  a  record  type  (Tsichritzis  and  Lochovsky,  1977:21).  To 
illustrate.  Figure  2-4  shows  a  record  type  THESIS_INFO  with  four  data 
items:  THESIS_1D_NR,  AUTHOR,  SUBJECT,  and  COMPONENT.  A  particular  group 
of  these  data  items  is  called  a  record  and  a  particular  data  item  is 
called  a  data  item  value  (Tsichritzis  and  Lochovsky,  1977:21). 


THESISJD_NR 

AUTHOR 

SUBJECT_AREA 

COMPONENT 

AFIT/GEM/LSM89S-6 

David  Clark 

Vehicle  Maintenance 

Survey 

Record  ^ 

AFIT/GLM/LSY/91S-27 

Thomas  Harkenrider 

Hospital  Supply 

Software 

AFIT/GLWENY/89S-25 

Dennis  Green 

Transport  Aircraft 

Survey 

AFrr/GIR/LSC/90D-2 

Alan  Constantian 

Hospitals 

Questionnaire 

Figure  2-4.  Record  Type  THESIS_INFO 


The  DBMS  provides  the  flexibility  of  allowing  the  user  access  to 
the  data  in  many  different  forms  (Senn,  1984:367;  Fleming  and  von  Halle, 
1989:4).  A  relational  DBMS  formats  the  data  into  a  two-dimensional 
table.  In  this  table,  the  rows  can  be  regarded  as  records  and  the 
columns  as  data  item  values  (Senn,  1984:375).  The  data  is  accessed 
using  a  primary  key.  A  primary  key  is  a  data  item  which  must  uniquely 
identify  each  record  (Fleming  and  von  Halle,  1989:16).  If  one  data  item 
cannot  uniquely  identify  one  record,  multiple  data  items  can  be  used  as 
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the  primary  key.  The  multiple  data  items  are  collectively  called  a 


concatenated  key  (Martin,  1981:44). 

The  data  stored  in  a  data  base  can  be  used  by  multiple  researchers 
with  each  researcher  accessing  only  the  portion  or  view  of  the  data 
which  is  required  for  the  particular  research  project  (Martin,  1981:2). 

A  view  is  the  part  of  the  data  base  which  is  visible  to  the  user. 

Figure  2-5  shows  a  view,  THESIS_VIEW,  which  is  made  up  of  a  portion  of 
the  THESIS_INFO  record  type. 


Record  Type:  THESISJNFO 


THESIS_ID_NR  AIJTHOR  SUBJECT_AREA  COMPONENT 


AFrr/GEMLSNV89S-6 

David  Clark 

j  Vehicle  Maintenance 

Survey 

AFIT/GLMLSY/91S-27 

Thomas  Harkenrider  Hospital  Supply 

Software 

AFIT/GIMENY/89S-2S 

Dennis  Green 

Transport  Aircraft 

Survey 

AFrr/GIR/LSC/90D-2 

Alan  Constantian 

Hospitals 

Questionnaire 

View:  THESIS_VIEW 

THESISJD_NR  AUTHOR  SUBJECT_AREA 


AFrT/GENyLSNk89S-6 

David  Clark 

Vehicle  Maintenance 

AFrT/GLWLSY/91S-27 

Thomas  Harkenrider 

Hospital  Supply 

AFIT/GLM'ENY/89S-25 

Dennis  Green 

TransportAircraft 

AFrr/GIR/LSC/900-2 

Alan  Constantian 

Hospitals 

Figure  2-5.  View  From  Record  Type  THESIS  INFO 


A  view  can  also  be  composed  of  subsets  from  multiple  record  types. 
To  continue  the  example  from  above,  another  record  type,  ADVISOR  INFO, 
contains  three  data  items;  THESIS  ID  NR,  ADVISOR,  and  DEPARTMEN'T . 
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Record  Type:  THESISJNFO 

THESIS  JD_NR  AUTHOR 

SUBJECT_AREA 

COMPONENT 

AFIT/GEM/LSM/89S-6 

‘  David  Clark 

Vehicle  Maintenance 

Survey 

AFIT/GLM/LSY/91S-27 

Thomas  Harkenrider 

Hospital  Supply 

Software 

AFIT/GLM/ENY/89S-25 

Dennis  Green 

Transport  Aircraft 

Survey 

AFIT/GIR/LSC/90D-2 

AlanConstantian 

Hospitals 

Questionnaire 

Record  Type:  ADVISORJNFO 
THESIS  ID  NR 


ADVISOR 


DEPARTMENT 


AFIT/GEMiSM/89S-6 

Robert  McCauley 

AFIT/LSM 

AFIT/GLM/LSY/91S-27 

Kevin  Grant 

AFIT/LSY 

AFIT/GLWENY/89S-25 

Robert  Calico 

AFIT/ENY 

AFIT/GIR/LSC/90D-2 

Larry  Emmelhaini 

AFIT/LSC 

)_TEAM 

THESISJNFO. 

THESIS  INFO. 

ADVISOR  INFO. 

THESIS  JD_NR 

AUTHOR 

ADVISOR 

AFIT/GEM/LSM/89S-6 

David  Clark 

Robert  McCauley 

AFIT/GLMfLSY/9lS-27 

Thomas  Harkenrider 

Kevin  Grant 

AFIT/GLWENY/89S-25 

Dennis  Green 

Robert  Calico 

AFIT/GIR/LSC/90O-2 

Alan  Constantian 

Larry  Emmelhainz 

Figure  2-6.  View  From  Multiple  Record  Types 


Figure  2-6  displays  a  view,  THESIS  TEAM,  consisting  of  data  items  from 
both  THESISINFO  and  ADVISOR_INFO  record  types . 

Advantages  ai  Information  Systems .  Information  systems  allow  for 
centralized  control  of  the  data  by  an  administrator.  The  administrator 
can  also  enforce  the  standards  for  data  handling  and  ensure  the  security 


2-29 


of  the  da+ ’ .  Information  systems  provide  a  single  location  for  storage 
of  the  data.  By  storing  data  in  a  single  location  accessible  to 
everyone  who  needs  the  data,  redundancy  is  reduced  because  multiple 
copies  of  the  data  are  no  longer  needed.  The  decrease  in  redundancy 
also  improves  the  integrity  of  the  data,  because  it  is  more  feasible  to 
maintain  only  one  copy.  Finally,  information  systems  allow  different 
researchers  to  use  the  same  data  but  access  it  with  different  views. 

This  flexibility  improves  ease  of  use  and  enhances  interaction  between 
the  researchers  (Diehr,  1989:14-16). 

Disadvantages  of.  Information  Systems .  The  costs  of  developing  and 
operating  an  information  system  are  its  major  disadvantages.  The  costs 
incurred  from  using  an  information  system  to  manage  the  data  can  be 
measured  by  the  cost  of  purchasing  and  setting  up  the  system,  converting 
the  data  to  a  format  compatible  with  the  information  system,  and 
upgrading  the  hardware  on  which  the  system  will  run.  Additionally,  the 
development,  operation,  and  maintenance  of  an  information  system  can  be 
very  expensive;  however,  the  advantages  listed  above  provide  savings 
which  outweigh  the  costs  in  almost  all  environments  (Diehr,  1989:3), 

Information  System  Development .  Many  information  systems  are 
created  using  the  systems  development  life  cycle  described  by  James  Senn 
in  his  book.  Analysis  and  Design  slL  Information  Systems .  The  activities 
in  Senn's  model  include  preliminary  investigation,  determination  of 
requirements,  development  of  prototype  system,  design  of  system, 
development  of  software,  systems  testing,  and  implementation  (Senn, 
1984:18) . 
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Preliminary  Investigation .  A  preliminary  investigation 


begins  when  a  person  or  department  has  a  requirement  that  can  be 
satisfied  with  an  information  system.  The  investigation  is  comprised  of 
clarifying  the  request,  studying  the  feasibility  of  the  request,  and 
scheduling  the  development  of  the  request  (Senn,  1984:18-19). 

Initially,  the  request  must  be  clarified  to  ensure  that  the 
problem  is  understood  by  the  users,  managers,  and  analysts.  Once  the 
problem  is  understood,  the  analysts  or  managers  must  make  sure  that  the 
proposed  system  is  feasible  (Senn,  1984:18-19).  The  feasibility  can  be 
determined  through  a  careful  analysis  of  the  environment  within  •.•■hich 
the  information  system  will  be  used.  The  main  question  of  feasibility  is 
whether  the  needs  of  the  user  can  be  cost-effectively  satisfied  by  using 
this  system  (Nijssen  and  Halpin,  1989:29).  After  the  system  has  been 
judged  feasible,  the  development  process  should  be  scheduled.  The 
schedule  is  based  upon  the  estimated  cost,  priority,  completion  time, 
and  personnel  requirements.  These  estimates  determine  which  projects 
should  be  developed  with  current  resources  and  which  should  be  put  on 
hold  until  more  resources  become  available  (Senn,  1984:19). 

Determination  of  Requirements .  As  with  any  development,  the 
requirements  of  a  system  must  be  determined  before  the  design  process 
can  begin.  This  step  consists  of  a  thorough  investigation  of  the 
current  system.  Analysts  must  talk  to  the  people  who  use  the  system  to 
get  an  idea  of  how  it  works.  This  also  gives  analysts  a  chance  to  find 
out  what  the  new  system  should  include.  In  addition  to  interviewing  t)ie 
personnel,  the  analysts  must  examine  any  documents  or  forms  which 
further  describe  the  process  (Senn,  1984:20). 
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Development  Prototype  System.  Even  after  the  preliminary 
investigation  and  determination  of  the  requirements,  the  complete  design 
of  the  system  may  remain  unresolved.  At  this  point,  a  prototype  can  be 
developed  to  evaluate  possible  solutions  (Senn,  1984:20)  A  prototype 
can  also  provide  the  users  with  a  hands-on  version  of  the  system.  With 
this  interaction,  the  user  may  think  of  other  features  which  are  needed 
in  the  new  system  (Lazinger,  1987:11-12).  Additionally,  the  prototype 
can  reduce  the  risk  of  using  new  or  untested  designs.  A  test  of  these 
designs  can  be  performed  with  a  prototype  before  beginning  the 
development  of  the  system.  Another  gain  from  prototyping  is  that  any 
information  gathered  during  the  test  of  the  prototype  can  be  utilized  in 
the  development  of  the  final  system  (Senn,  1984:20). 

Design  of.  System.  The  designing  of  the  system  creates  a  set 
of  specif ications  that  will  be  given  to  the  programmers  to  develop  the 
software.  This  specification  contains  the  detailed  structures  of  the 
input  and  output  of  the  system.  Preparation  of  the  data  needed  to  make 
it  usable  to  the  system  must  be  addressed  as  well  as  the  actual  method 
of  data  entry  into  the  system.  Data  can  be  entered  from  the  keyboard  or 
read  from  a  document  (Senn,  1984:287). 

The  output  of  the  data  should  also  be  reviewed.  The  analysts  must 
decide  whether  the  output  from  the  new  system  will  be  presented  on  the 
monitor  or  printed  in  a  report.  If  the  data  is  printed,  the  format  of 
the  report  should  be  designed  to  enhance  readability  (Senn,  1984:231). 

The  system  must  be  designed  in  modules  representing  the  system's 
individual  functions.  These  functions  should  be  relatively  small  and 
self-contained  (Humphrey,  1990:115).  Because  these  modules  are 
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functionally  independent,  the  system  is  easier  to  design  and  maintain 
(Pressman,  1987:230). 

Development  of  Software .  During  this  portion  of  the  design, 
the  programmers  take  the  specification  developed  by  the  analysts  and 
begin  to  write  the  software  which  makes  up  the  information  system.  The 
programmers  may  also  decide  that  some  functions  can  be  performed  by 
buying  commercial  software  and  merging  it  with  software  they  are 
writing.  In  some  cases,  it  may  be  cheaper  to  buy  the  software  instead 
of  building  it.  If  the  programming  staff  is  not  large  enough  to  handle 
the  entire  development  process,  or  does  not  have  time  to  complete  the 
development,  purchasing  software  becomes  a  very  realistic  way  to  save 
money  and  time  (Senn,  1984:375). 

Systems  Testing  Once  the  software  is  developed,  the 
analysts  begin  to  test  each  line  of  the  program  to  determine  if  the 
requirements  have  been  fulfilled  (Senn,  1984:488).  Other  test  cases 
examine  the  software  against  the  specifications  which  were  developed 
during  the  previous  step  (Senn,  1984:491).  The  lowest  level  of  testing, 
unit  testing,  ensures  that  individual  functions  perform  as  they  should 
(Pressman,  1987:501).  As  stated  earlier,  these  functions  are  designed 
into  separate  modules  of  code.  When  modules  complete  testing,  they  are 
integrated  to  form  a  larger  module,  which  in  turn  must  be  tested  (Senn, 
1984:491-494).  This  integration  testing  continues  until  all  the  modules 
have  been  integrated  into  the  final  product.  The  final  product  is  then 
tested  to  ensure  that  it  is  complete  and  meets  requirements  (Senn, 

1984  -.494-495)  . 
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Implementation .  With  testing  complete,  actions  must  be 
taken  to  implement  the  system.  The  implementation  falls  into  three 
general  categories:  training,  conversion,  and  review  (Senn,  1984:525). 

Training .  Two  groups  need  to  be  trained:  the 
operators,  or  the  personnel  who  will  run  the  system;  and  the  users  of 
the  system.  The  operators  need  training  in  how  the  system  works  and 
what  steps  need  to  be  taken  if  an  error  occurs.  The  users  need  to  be 
trained  on  how  to  use  the  system  to  enter  and  retrieve  data.  The  source 
of  training  should  also  be  explored.  Training  can  be  provided  by 
vendors  or  in-house  personnel.  The  quality  and  cost  of  the  training 
will  be  a  driving  factor  in  the  choice  of  the  training  source  (Senn, 

1984 : 525-530)  . 

Conversion .  Some  method  of  converting  from  the 
current  system  to  the  new  system  must  be  devised.  The  conversion 
process  can  be  performed  using  any  of  the  following  methods:  (1)  run 
both  systems  in  parallel,  allowing  personnel  to  get  accustomed  to  the 
new  system  and  slowly  transfer  their  work  until  the  old  system  can  be 
removed;  (2)  replace  the  old  system,  forcing  personnel  to  use  the  new 
system;  (3)  install  a  pilot  system  in  one  department  to  test  any  new 
technology  before  making  it  available  to  the  entire  organization;  or  (4) 
implement  the  new  system  in  phases  to  deal  with  the  complexity  of  the 
system  or  the  organization  (Senn,  1984:530-535). 

Review.  After  the  system  has  been  implemented,  an 
evaluation  is  necessary  to  determine  if:  (1)  the  system  is  working 
correctly,  (2)  personnel  are  using  the  system,  and  (3)  changes  to  the 
system  need  to  be  made.  Maintainers  of  the  system  can  also  use  the 
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results  from  this  review  to  determine  what  new  capabilities  need  to  be 
added  (Senn,  1984:543). 

Software  Development  Models .  Senn's  systems  development  life 
cycle  is  based  on  the  waterfall  model  introduced  by  Royce  in  1970. 
Currently,  Royce 's  waterfall  model  (and  its  many  variants)  is  the  most 
widely  accepted  software  development  process  model.  However,  the 
waterfall  does  have  some  problems  (Humphrey,  1990:249).  A  review  of  the 
model  and  a  major  alternative  to  it  are  presented  below. 

Waterfall  Model .  Royce 's  original  waterfall  model  was 
composed  of  seven  steps:  system  requirements,  software  requirements, 
analysis,  program  design,  coding,  testing,  and  operations  (Humphrey, 
1990:250).  The  model  is  shown  in  Figure  2-7.  The  first  three  steps  in 
Royce 's  model  tie  directly  into  the  first  two  steps  of  Senn's  model. 

The  third  step  in  Senn's  model  introduces  prototyping  to  improve  the 
developer's  understanding  of  the  problem  and  its  solution  requirements. 
Royce 's  form  of  prototyping  calls  for  a  "build  it  twice"  sequence  which 
is  performed  concurrently  with  the  first  three  steps  of  the  model 
(Kameny  and  others,  1989:6).  The  last  four  steps  of  the  waterfall  model 
correspond  directly  to  Senn's  final  four  steps. 

Neither  the  waterfall  model  nor  its  derivatives  encompass  all 
aspects  of  software  development.  Although  Royce  and  Senn  recognized  the 
need  for  prototyping,  both  limit  the  degree  to  which  this  technique  is 
used.  For  instance,  the  development  of  software  in  an  environment  of 
rapidly  changing,  or  undefined  requirements,  necessitates  the  use  of  a 
more  flexible,  iterative  technique  to  ensure  the  system  that  is  built 
meets  the  customers  "real"  needs.  The  next  section  examines  a  model 
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Figure  2-7.  Waterfall  Model  of  the  Software  Process  (Humphrey, 
1990:250) 


that  provides  such  a  framework  for  software  development  (Boehm,  1988:63- 
65;  Humphrey,  1990:249). 

Spiral  Model .  The  spiral  model  of  software  development 
evolved  from  the  experience  gained  by  using  the  waterfall  model  for 
large  government  software  projects.  It  was  developed  to  accommodate  a 
variety  of  previous  software  development  models  as  special  cases  and  to 
provide  guidance  for  modeling  a  given  software  situation  (Boehm, 
1988:64-65) . 

As  its  name  implies,  the  spiral  model  approaches  software 
development  in  a  spiral  fashion.  Figure  2-8  provides  an  illustration  of 
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the  model  which  should  be  viewed  as  starting  at  the  innermost  end  and 
proceeding  clockwise  through  a  series  of  phases.  The  purpose  of  the 
spiral  line's  continuous  movement  away  from  the  origin  is  to  reflect  the 
cumulative  cost  of  the  system's  development.  Similarly,  the  crossing 
axes  are  provided  to  show  the  amount  of  progress  made  at  a  given  point 
in  the  program  (Boehm,  1988:65). 

Each  new  cycle  of  the  spiral  begins  by  defining  the  objectives  of 
the  software  product  in  terms  of  its  desired  performance,  functionality, 
and  flexibility  characteristics.  Alternative  implementations  are  then 
identified  along  with  their  associated  constraints.  Constraints  may 
include  such  items  as  cost,  schedule,  and  technical  limitations  (Boehm, 
1988:65)  . 

The  upper  and  lower  right  quadrants  of  the  model  are  described  by 
Boehm  as  follows: 

The  next  step  is  to  evaluate  the  alternatives  relative  to  the 
objectives  and  constraints.  Frequently,  this  process  will 
identify  areas  of  uncertainty  that  are  significant  sources  of 
risk.  If  so,  the  next  step  should  involve  the  formulation  of  a 
cost-effective  strategy  for  resolving  the  sources  of  risk.  This 
may  involve  prototyping,  simulation,  benchmarking,  reference 
checking,  administering  user  questionnaires,  analytic  modeling,  or 
combinations  of  these  and  other  risk-resolution  techniques. 

Once  the  risks  are  evaluated,  the  next  step  is  determined  by  the 
relative  remaining  risks.  If  performance  or  user- interface  risks 
strongly  dominate  program  development  or  internal  interface- 
control  risks,  the  next  step  may  be  an  evolutionary  development 
one:  a  minimal  effort  to  specify  the  o-/erall  nature  of  the 
product,  a  plan  for  the  next  le'/el  of  prototyping,  and  the 
development  of  a  more  detailed  prototype  to  continue  to  resolve 
the  major  risk  issues. 

If  this  prototype  is  operationally  useful  and  robust  enough  to 
serve  as  a  low- risk  base  for  future  product  evolution,  the 
subsequent  risk-driven  steps  would  be  the  evolving  series  of 
prototypes  going  toward  the  right  in  Figure  2-8.  In  this  case, 
the  option  of  writing  specifications  would  be  addressed  but  not 
exercised.  Thus,  risk  considerations  can  lead  to  a  project 
implementing  only  a  subset  of  all  the  potential  steps  in  the 
model . 
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Cumulative  cost 


2-38 


fell  Model  of  the  Software  Prc>cei;s  (Hoelim 


On  the  other  hand,  if  previous  prototyping  efforts  have  already 
resolved  all  of  the  performance  or  user- interface  risks,  and 
program  development  or  interface-control  risks  dominate,  the  ne::t 
step  follows  the  basic  waterfall  approach,  modified  as  appropriate 
to  incorporate  incremental  development.  (Boehm,  1988:65) 

During  the  last  quadrant  of  the  spiral  model,  plans  are  prepared 

for  the  next  cycle.  These  plans  could  include  the  partitioning  of  the 

product  into  several  components  that  may  be  developed  in  separate 

parallel  spiral  cycles.  The  final  activity  in  this  quadrant,  and  the 

cycle  as  a  whole,  is  the  "review- and- commitment"  step.  This  step  "may 

range  from  an  individual  walk-through  of  the  design  of  a  single 

programmer's  component  to  a  major  requirements  review  involving 

developer,  customer,  user,  and  maintenance  organizations."  The 

ostensible  end  goal  of  the  "review-and-commitment "  step  is  to  determine 

if  future  cycles  through  the  spiral  are  needed  and  supported  (Boehm, 

1988:65) . 

Wolff  used  the  spiral  model  for  a  system  development  and  found 
that  some  areas  of  the  model  did  not  give  a  clear  indication  of  what  was 
occurring  in  the  development.  Wolff  determined  that  as  the  knowledge 
base  of  the  system  grew,  the  spiral  model  was  not  able  to  keep  up.  In 
an  effort  to  maintain  a  current  knowledge  base,  Wolff  modified  the 
spiral  model.  The  new  spiral  model  contains  two  additional  operations 
or  activities:  (1)  gathering  new  knowledge  and  adding  it  to  the 
knowledge  base;  (2)  reviewing,  analyzing  and  rationalizing  what  is  in 
the  knowledge  base.  These  activities  are  followed  by  executing  plans 
which  may  have  been  created  during  the  cycle  (Wolff,  1989:140) . 
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Before  one  can  solve  a  problem  or  make  improvements  to  a  current 
situation,  it  is  important  to  understand  your  environment  and 
alternatives.  This  chapter  documented  an  exploration  of  the  many  topics 
considered  germane  to  this  study's  problem  and  solution  domains.  It 
began  with  an  overview  of  the  area  of  research,  which  included  a  brief 
look  at  the  AFIT  and  LS-specific  research  environments,  and  some  major 
difficulties  facing  student  researchers.  The  focus  then  shifted  to  the 
concept  of  reuse,  its  application  in  the  software  development  arena,  and 
its  pertinence  to  this  study.  The  final  section  reviewed  some  key 
information  systems  principles  and  software  development  models . 


Ill- 


Overview 

The  goal  of  this  research  was  to  design,  develop,  test,  and 
evaluate  an  initial  prototype  information  system  to  enhance  the  conduct 
and  management  of  academic  research  in  the  School  of  Systems  and 
Logistics  (LS)  at  the  Air  Force  Institute  of  Technology  (AFIT) .  This 
chapter  begins  with  an  explanation  of  why  the  spiral  life  cycle  model 
was  chosen  and  how  it  was  used  to  guide  the  activities  of  this  study. 

The  remaining  sections  describe  how  each  of  the  following  research 
objectives  were  satisfied: 

1 .  Describe  the  current  AFIT  research  environment . 

2.  Define  and  validate  the  AFIT  Research  Management  System  (ARMS) 
requirements . 

3 .  Analyze  alternatives  and  select  prototype  constraints . 

4 .  Design  and  develop  the  prototype  system. 

5.  Perform  an  operational  test  of  the  prototype  system. 

6 .  Analyze  and  interpret  operational  test  results . 

7.  Develop  recommended  path  for  follow-on  research. 

Spiral  Lils.  Cycle  Model 

The  spiral  life  cycle  model  was  selected  to  guide  this  study  for 
two  primary  reasons : 

1.  The  model's  iterative  nature  provides  a  flexible  approach  for 
developing  and  refining  prototype  systems. 

2.  The  model's  risk -driven  review  checkpoints  allows  for  early 
termination  of  a  project  when  it  is  becomes  too  risky  or 
cost-prohibitive  to  continue.  (Boehm,  1988:65) 
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As  stated  in  Chapter  II,  these  tenets  of  the  spiral  model  allow 
developers  to  refine  a  system's  requirements  by  completing  several 
cycles  before  the  product ion -quality  system  is  built.  This  research 
completed  an  initial  cycle  through  the  spiral  model  and  produced  the 
results  described  in  Chapters  IV  and  V. 

It  is  important  to  note  that  the  spiral  model  was  refined  for  use 
in  this  study.  The  authors'  implementation  represents  an  adaptation  of 
both  the  spiral  and  Senn  models  into  a  hybrid  approach.  The  new  model 
supplies  additional  structure  to  the  broad  guidelines  of  the  spiral  by 
mapping  a  set  of  detailed  steps,  the  research  objectives  for  this  study, 
into  the  original  spiral  model's  initial  cycle.  As  stated  previously, 
the  research  objectives  are  generally  patterned  after  Senn's  model 

Figure  3-1  illustrates  how  this  study's  research  objectives  were 
mapped  into  the  innermost  cycle  of  the  spiral  model.  The  names  used  to 
describe  the  quadrants  differ  slightly  from  those  presented  in  Chapter 
II,  but  the  basic  concept  and  goals  of  each  phase  remain  the  same. 

Problem  Analysis .  The  problem  analysis  phase  of  activities  was 
mapped  to  quadrant  I  of  the  spiral  model.  During  this  phase,  the 
authors  conducted  a  literature  review  and  completed  research  oojectives 
one  and  two.  The  goal  was  to  determine  the  objectives,  alternatives, 
and  constraints  of  this  research  effort.  The  outputs  of  this  phase 
included  the  general  understanding  of  the  AFIT  and  LS  research 
environments  presented  in  Chapter  II  and  a  validated  set  of  requirements 
for  the  prototype  ARMS. 

Risk  Analysis /Prototype  Development .  The  risk  analysis/prototype 
development  phase  for  this  project  corresponds  to  quadrant  II  of  the 


3-2 


QUADRANT  1 

Determine  objectives, 
alternatives,  constraints 

QUADRANT  II 

Evaluate  alternatives; 
develop  next-level  product 

ye  Problem  Analysis 
/  Objectives  #1  &  #2 

Risk  Analysis 

Objective 

Prototype  N 

Development  \ 

Objective  #4  \ 

\  Develop  Follow-on  Research 

Prototype  Test  and  Analysis  / 

N.  Objective  #7 

Objectives  #5  &  #6 

QUADRANT  IV 

QUADRANT  III 

Plan  next  phases 

Verify  next-level  product 

Figure  3-1.  Adapted  Initial  Cycle  of  Spiral  Model  (Boehm,  1988:64} 


spiral  model  and  the  goals  of  evaluating  alternatives,  and 
identifying/resolving  risks.  These  goals  were  met  by  using  the 
validated  requirements  document  produced  in  the  problem  analysis  phase 
to  complete  research  objectives  three  and  four.  The  ma^or  end  products 
of  this  phase  were  the  prototype  system  and  documentation  to  operate  and 
evaluate  it. 

Prototype  Test  and  Analysis .  Research  objectives  five  and  six 
were  conducted  during  this  phase  to  meet  quadrant  Ill's  goal  of 
verifying  the  next-level  product.  The  analysis  of  tJie  operational  test 
conducted  during  this  phase  directly  fed  the  follow-on  research  phase 
with  information  on  how  the  prototype  could  be  improved. 
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Develop  Follow-on  Research .  The  purpose  of  the  spiral  model's 
fourth  quadrant  is  to  develop  plans  for  the  next  cycle  through  the  model 
(Boehm,  1988:64).  Research  objective  seven,  which  involved  the 
development  of  recommendations  for  improving  the  prototype  and 
conducting  corollary  studies,  was  completed  to  meet  the  goal  of  this 
phase . 

Research  Objective  One  -  Describe  the  Current  AFIT  Research  Environment 

A  detailed  description  of  the  current  AFIT  research  environment 
was  needed  to  clearly  understand  the  objectives,  alternatives  and 
constraints  of  the  research  problem.  The  first  step  was  to  conduct  a 
structured  interview  with  the  research  directors  for  .AFIT's  School  of 
Engineering  (EN) ,  School  of  Systems  and  Logistics  (LS) ,  and  School  of 
Civil  Engineering  and  Services  (DE) .  The  interviews  had  the  following 
three- fold  purpose: 

(1)  to  gain  an  understanding  of  the  general  structure,  management 
philosophy,  and  overall  strengths  and  weaknesses  of  each 
school ' s  research  program; 

(2)  to  present  the  basic  tenets  of  this  research  proposal  and 
obtain  general  feedback  on  the  intent  of  the  overall  project; 
and 

(3)  to  solicit  recommendations  about  desired  requirements  for 
the  research  products  reuse  program  and  the  prototype 
information  system. 

Appendix  A  contains  the  outline  used  to  conduct  the  structured 
interviews.  Interview  findings  were  divided  into  two  major  categories 
of  information:  (1)  AFIT  and  LS-specific  research  programs,  and  (2) 
suggested  requirements  for  the  prototype  ARMS.  The  information 
concerning  the  overall  AFIT  and  LS-specific  research  programs  is 
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described  in  Chapter  II,  and  the  specific  suggestions  for  the  prototype 
ARMS  are  discussed  in  Chapter  IV. 

A  literature  review,  including  an  examination  of  the  major 
resources  available  tc  student  researchers,  was  also  conducted  to 
complete  the  overall  view  of  the  AFIT  research  environment.  The  review 
specifically  investigated  research  guidance  and  resources  available  on 
the  APIT  campus,  as  well  as  the  facilities  provided  by  research¬ 
sponsoring  activities  at  Wright  Patterson  Air  Force  Base,  Ohio. 

Research  Objective  Two  -  Define  and  Validate  the  ARMS  Requirements 

The  primary  goal  of  this  research  objective  was  to  produce  a 
validated  document  that  contained  the  requirements  for  the  prototype 
ARMS.  A  chief  concern  of  the  researchers  during  this  objective  was  to 
ensure  that  the  system's  many  nonautomated  requirements  (particularly  in 
the  policy  area)  were  not  overlooked. 

A  proposed  set  of  requirements  for  the  prototype  ARMS  was 
developed  based  on  the  recommendations  received  during  the  interviews 
conducted  in  research  objective  one  and  the  researchers'  personal 
insights  gained  during  the  formulation  of  this  research  study.  Due  to 
the  prototype  nature  of  this  study,  most  of  the  requirements  for  the 
ARMS  were  stated  in  general  terms.  It  was  anticipated  that  this 
approach  would  promote  brainstorming  by  personnel  reviewing  and 
validating  the  prototype  requirements.  This  approach  also  ensured  that 
a  pre-defined  solution  was  not  specified  before  the  requirements  were 
validated . 
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To  facilitate  an  AFIT-wide  faculty  review  of  the  proposed  ARMS 
requirements,  the  authors  developed  a  draft  functional  description  (FD) 
for  the  prototype.  Congruent  with  the  approach  discussed  above,  several 
sections  of  the  initial  FD  (Appendix  C)  were  not  fully  developed  for  the 
validation  effort.  Specifically,  some  portions  of  sections  three,  four, 
and  five  would  have  required  a  high  degree  of  knowledge  about  the 
proposed  system's  design.  The  cover  letter  distributed  with  the  draft 
document  asked  reviewers  to  validate  and  comment  on  the  proposed 
requirements  for  the  ARMS . 

The  results  of  the  validation  effort  were  analyzed  and  used  to 
update  the  system's  FD.  The  analysis  accomplished  during  this  step  was 
centered  on  determining  if  any  proposed  changes  or  additions  were 
consistent  with  the  purposes  of  the  ARMS.  A  description  of  the 
validation  results  and  analysis  is  provided  in  Chapter  IV  .  The  updated 
ARMS  FD  is  contained  in  Appendix  K. 

Qbjsctjvg  Three  -  Analyze  Alternatives  and  Select  Prototype 

Constraints 

Three  major  decisions  were  made  to  complete  this  objective.  The 
first,  and  perhaps  most  important,  action  required  the  authors  to 
analyze  the  alternative  approaches  for  meeting  the  validated 
requirements  developed  in  research  objective  two.  The  following  three 
alternatives  were  considered  for  this  study:  do  nothing,  modify  an 
existing  system,  and  develop  a  prototype.  As  indicated  earlier  in  this 
report,  the  alternative  to  develop  a  prototype  was  selected.  The 
justification  for  this  decision  can  be  found  in  Chapter  IV. 
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The  second  major  decision  involved  paring  down  the  ARMS 
requirements  to  a  subset  that  could  be  implemented  as  part  of  the 
initial  prototype  ARMS.  The  first  step  in  this  process  was  to  defer  all 
nonautomated  requirements  needed  to  fully  implement  a  research  products 
reuse  program.  The  second  step  involved  an  effort  to  decide  which 
automation  requirements  to  include  in  the  initial  design  of  the 
prototype.  The  goal  of  this  step  was  to  ensure  that  the  selected 
requirements  would  demonstrate  the  potential  usefulness  of  the  system. 
Those  requirements  not  selected  for  automation  in  this  step  were  used  to 
form  the  foundation  for  one  of  the  recommended  paths  for  follow-on 
research  discussed  in  research  objective  seven. 

The  selection  of  a  host  computer  system  and  development  tools  was 
the  final  decision  needed  before  the  prototype  could  be  designed.  To 
accomplish  this  task,  an  evaluation  of  available  AFIT  computing 
resources  (hardware  and  software)  was  conducted  with  the  assistance  of 
personnel  working  in  AFIT's  Directorate  of  Communications  and  Computer 
Systems.  The  results  of  this  decision  are  delineated  in  Chapter  IV. 

Research  Qbjgdtjvg  Four  -  Design  and  Develop  the  Prototype  System 

Based  oi;  the  decisions  made  in  research  objective  three,  the 
prototype  system  was  developed.  Specific  emphasis  was  placed  on 
documenting  the  system's  design  and  operation  to  ensure  the  initial 
prototype  could  be  efficiently  operated  during  the  operational  test,  and 
subsequently  improved  during  follow-on  research  efforts. 

The  detailed  system  design  for  the  ARMS  was  completed  using  a 
combination  of  software  engineering  techniques.  The  design  approach 
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included  the  use  of  context  and  entity  relationship  diagrams  to  model 
the  current  problem  and  solution  environments.  In  addition,  a  set  of 
revision  control  procedures  was  established  and  followed  throughout  the 
coding  process  to  ensure  the  system's  development  was  managed  in  an 
orderly  manner.  Chapter  IV  and  Appendix  K,  Section  3,  contain  a  summary 
and  detailed  explanation  of  the  ARMS'  design,  respectively. 

An  initial  set  of  operating  instructions,  in  the  form  of  a  draft 
user's  guide,  was  developed  to  help  personnel  use  the  system  during  the 
operational  test.  The  development  of  a  similar  document  for  performing 
system  administration  functions,  such  as  adding,  deleting,  or  changing 
the  data  in  the  information  system,  was  contemplated  but  deemed 
unnecessary  for  this  study.  The  user's  guide  developed  during  this  step 
is  contained  in  Appendix  F. 

Research  Qb.ie,gtiy.£  Five  -  Ee.r£fl.rip  an  QBarablonal  Test  slL  iM  Prototype 

In  order  to  evaluate  the  technical  adequacy  and  suitability  of  the 
prototype  ARMS,  an  operational  test  of  the  system  was  conducted.  The 
steps  to  meet  this  objective  involved  populating  the  information  system 
with  initial  data,  developing  the  evaluation  tool,  and  conducting  the 
test . 

The  effort  to  populate  the  prototype  ARMS  was  conducted 
concurrently  with  the  system's  development.  This  approach  permitted  the 
use  of  the  same  data  set  for  both  pre-operational  readiness  and 
operational  testing.  Based  on  the  implied  quality  of  their  content, 
award-winning  theses  were  used  to  derive  most  of  the  information  in  the 
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initial  data  set.  A  more  precise  criteria  will  likely  be  needed  if  a 
production-quality  ARMS  is  placed  into  operational  use. 

Prior  to  conducting  the  operational  test,  the  authors  researched 
the  availability  of  an  appropriate  evaluation  instrument  for  assessing 
the  technical  adequacy  and  operational  suitability  of  the  ARMS.  The 
evaluation  questionnaire  used  by  ARMS  testers  consisted  of  adapted 
questions  from  an  instrument  used  in  a  1990  AFIT  thesis  (McMurry, 
1990:90-92).  The  specific  structuring  decisions  employed  in  building 
the  ARMS  evaluation  form  (Appendix  E)  are  discussed  in  Chapter  IV. 

A  two-phased  operational  test  was  conducted  using  samples  from  the 
new  student,  current  student,  and  LS  faculty  populations.  During  the 
first  phase  of  testing,  newly  arrived  students  in  the  class  of  1993 
evaluated  two  major  subsystems  of  the  ARMS,  the  Research  Topic  Selection 
Subsystem  (RTSS)  and  Research  Products  Reuse  Subsystem  (RPRS) .  This 
phase  of  testing  was  aimed  at  receiving  feedback  from  evaluators  who  had 
not  been  influenced  by  a  knowledge  of  the  current  environment . 
Additionally,  the  newly -arrived  students  were  expected  to  be  a  source  of 
fresh  ideas. 

Phase  two  of  the  operational  test  was  corducted  with  LS  faculty 
members  and  students  in  the  class  of  1992.  During  this  phase,  the 
prototype's  RTSS,  RPRS,  and  Research  Management  Subsystem  (RMS)  were 
evaluated  by  people  considered  experienced  in  the  art  of  research  and 
the  AFIT  research  environment . 

Se.sgarch  objective  Six  -  Analyze  and  Interpret  Operational  Test  Results 

During  the  conduct  of  the  operational  test,  participating  faculty 
members  and  students  completed  evaluation  instruments.  The  evaluation 
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tool's  design  was  such  that  it  facilitated  assessments  of  the  system's 
technical  adequacy  and  operational  suitability.  For  the  purpose  of  this 
study,  technical  adequacy  pertained  to  the  relative  maturity  of  the 
prototype's  design  and  implementation.  The  suitability  evaluation 
subjectively  considered  the  applicability  and  desirability  of  the 
proposed  system  to  serve  as  a  productivity  enhancement  tool  within  the 
LS  research  environment. 

To  assess  the  technical  adequacy  of  the  system,  an  analysis  was 
performed  on  the  evaluation  questions  related  to  the  basic  performance 
characteristics  of  the  system.  Subjective  ratings  were  requested  on 
such  factors  as  ease  of  use,  speed  of  data  retrieval,  clarity  of  data 
presentation,  and  a  number  of  other  human- to- system  interface 
considerations.  Suitability  was  assessed  by  analyzing  the  evaluation 
responses  about  the  proposed  system's  desirability  and  potential  to 
enhance  the  AFIT  research  environment . 

The  assessment  of  the  above  factors  had  a  two -fold  purpose;  1)  to 
determine  what  changes  should  be  made  to  the  prototype  system;  and  2)  to 
decide  if  the  project  should  be  terminated  at  the  end  of  this  spiral 
model  cycle  or  recommended  for  continued  research. 

Research  Objective  Seven  -  Develop  Recommended  Path  for  Follow-On 
Research 

The  exploratory  nature  of  this  study  required  the  proper 
completion  of  this  objective.  Therefore,  items  for  follow-on  research 
were  gathered  and  documented  during  the  conduct  of  research  objectives 
one  through  six.  This  approach  reduced  the  documentation  and  completion 
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of  this  objective  to  a  minor  effort  of  partitioning  the  issues  into  the 
two  main  categories  described  below. 

Follow-on  Development  of  the  Prototype  Svstem.  Items  placed  in 
this  category  focused  on  improving  the  capability  of  the  prototype 
system.  Specific  candidate  items  included  requirements  not  selected  for 
automation  during  research  objective  three  and  the  changes  recommended 
by  users  performing  the  operational  test  described  in  research  objective 
five . 

Corollary  Studies .  This  category  contains  suggested  corollary 
studies  to  investigate  how  the  nonautomated  requirements  and 
administrative  oversight  for  the  ARMS  can  be  implemented.  The  primary 
items  for  this  category  were  derived  during  research  objectives  two  and 
three . 
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The  structuring  of  this  study's  methodology  in  the  form  of  a 
software  development  life  cycle  resulted  in  the  completion  of  several 
objectives  that  did  not  bear  traditional  research  "findings." 

Therefore,  this  chapter  presents  a  more  in-depth  discussion  of  how  the 
first  five  research  objectives  were  accomplished  and  provides  the 
findings  for  the  sixth  research  objective.  A  discussion  of  the  study's 
seventh,  and  final,  research  objective  is  deferred  until  Chapter  V. 

Research  Objective  One  Results 

The  authors  used  the  structured  interviews  (Appendix  A)  with  the 
research  directors  and  a  review  of  the  literature  to  document  a  general 
understanding  of  the  current  research  environment  described  in  Chapter 
II.  A  summary  matrix  of  the  research  directors'  responses  to  several 
interview  questions  is  provided  in  Appendix  B.  The  interviews  were  also 
used  to  obtain  feedback  concerning  the  requirements  for,  what  was  then 
termed,  the  research  products  reuse  program  (RPRP) . 

DE  and  LS  research  directors  endorsed  the  RPRP  and  provided 
several  recommendations  that  extended  its  functionality  (Duncan,  1991; 
Emmelhainz,  1991).  EN's  research  director  primarily  reserved  comment  on 
the  proposal,  but  indicated  that  alternatives  to  building  a  new  system 
should  be  considered  (Bridgman,  1991) .  This  suggestion  was  heeded  and 
an  evaluation  of  alternatives  is  described  later  in  this  chapter. 

Besides  confirming  the  need  for  the  RPRP,  the  DE  and  LS  research 


directors  focused  on  a  number  of  desired  improvements  in  a  second  area 


of  interest- -the  current  topic  selection  process.  The  directors 
suggested  that  an  increase  in  the  number  of  continuing  and  sponsored 
studies  could  be  realized  if  student  researchers  had  access  to  an 
automated  source  of  information  on  past  and  present  thesis  efforts.  As 
noted  in  Chapter  II,  no  current  system  specializes  in  providing  this 
type  of  information.  Along  with  the  benefits  of  increasing  certain 
types  of  studies,  the  DE  and  LS  research  directors  felt  that  an 
automated  topic  information  system  could  greatly  enhance  researcher 
productivity  (Duncan,  1991;  Emmelhainz,  1991) . 

The  interviews  also  highlighted  the  need  for  a  centralized  source 
of  infoirmation  for  monitoring  and  reporting  a  school's  research  program 
"health  and  status."  Although  automation  is  used  to  some  extent  for 
performing  research  management  functions,  many  of  the  current  systems 
provide  a  single  function  and,  in  most  cases,  contain  duplicate  data . 

The  DE  and  LS  research  directors  agreed  that  a  system  that  integrated 
research  program  information  would  be  a  valuable  resource,  but  they  did 
not  offer  detailed  recommendations  on  how  such  a  system  should  be 
constructed  (Duncan,  1991;  Emmelhainz,  1991) . 

Research  objective  one's  completion  yielded  two-fold  results. 
First,  the  authors  gained  an  understanding  of  the  general  structure, 
management  philosophy,  and  overall  strengths  and  weaknesses  of  each 
school's  research  program.  Second,  the  authors  obtained  feedback  on  the 
prototype  system.  The  feedback  came  in  the  form  of  several  new 
requirements  which  extended  this  study's  scope.  Besides  the  initial 
goal  of  improving  researcher  productivity  by  adapting  the  reuse  concept 
to  research,  the  study  incorporated  the  tasks  of  developing  an  aid  for 


4-2 


selecting  research  topics  and  a  framework  for  monitoring  the  overall 
academic  research  program.  To  meet  this  challenge,  the  authors  held 
several  informal  meetings  with  personnel  in  the  LS  Office  of  Thesis 
Research  to  develop  a  conceptual  model  of  the  current  LS  environment 
that  could  be  used  in  developing  the  prototype  ARMS. 

Research  Objective  Results 

Based  on  the  structured  interview  results  and  the  insights  gained 
during  the  formulation  of  this  study,  the  authors  developed  an  initial 
set  of  requirements  for  the  ARMS.  As  noted  in  Chapter  III,  the 
exploratory  nature  of  this  study  limited  the  degree  of  quantification 
that  could  be  used  in  specifying  the  system's  requirements.  This  factor 
was  not  considered  a  problem  since  the  underlying  aim  of  this  study  was 
to  determine  if  a  formal  ARMS  is  needed.  Future  research  efforts  to 
improve  the  prototype  should  address  the  need  for  a  more  measurable  set 
of  requirements  that  empirically  show  the  system's  effectiveness. 

To  facilitate  an  AFIT-wide  review  and  validation  of  the  proposed 
requirements  for  the  ARMS,  a  functional  description  (FD)  was  developed 
using  the  format  listed  in  DoD-STD-7935,  "Automated  Data  Systems 
Documentation. "  The  FD  (Appendix  C)  provided  an  overview  of  the 
existing  environment  and  addressed  how  the  new  system  was  expected  to 
impact  it.  Sections  3,  4,  and  5  in  Appendix  C  were  not  fully  developed 
because  specific  design  and  implementation  details  were  unknown  at  that 
time.  These  sections  were  significantly  updated  in  the  FD  produced  at 
the  end  of  this  study  (Appendix  K) . 
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Copies  of  the  initial  FD  were  distributed  to  the  following 
personnel  with  a  cover  letter  explaining  some  basic  guidelines  for 
reviewing  and  validating  the  document: 

a.  Directors  of  Research  and  Consulting  for  DE,  EN,  and  LS; 

b.  Director  of  Library  Services  (LD); 

c.  Director  of  the  LS  Information  Resource  Center  (LSI); 

d.  Department  Head  for  Government  Contract  Law  (LSL) ; 

e.  Department  Head  for  Logistics  Management  (LSM); 

f.  Department  Head  for  Contracting  Management  (LSP) ; 

g.  Department  Head  for  Quantitative  Management  (LSQ) , 

h.  Department  Head  for  Communication  and  Organizational  Science 
(LSR) ; 

i.  Department  Head  for  System  Acquisition  Management  (LSY) ;  and 

j .  Chief  of  the  Communications -Computer  System  Development 
Division  (SCV); 

In  addition  to  imposing  a  30 -day  suspense  for  responses,  the  cover 
letter  specifically  requested  comments  on  the  general  requirements 
listed  in  paragraphs  2.4  through  3 . 1  of  the  FD. 

Responses  were  received  from  DE,  EN,  LDE,  LSI,  LSR,  and  LSY  for  a 
response  rate  of  55  percent.  EN's  response  expressed  concern  about  the 
potential  implications  this  study  may  convey  about  the  quality  and  value 
of  AFIT  research.  The  authors  discussed  this  issue  with  the  EN  research 
director  and  reaffirmed  that  the  intent  of  this  study  was  to  enhance  the 
AFIT  research  program. 

The  remaining  FD  validation  responses  were  general  in  nature  and 
are  summarized  in  Appendix  D.  Several  comments  addressed  implementation 
decisions  that  will  need  to  be  made  before  a  production  quality  ARMS 
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could  be  placed  into  operation.  Some  of  these  issues  are  discussed  in 
Chapter  V  and  could  serve  as  follow-on  research  topics  if  this  study  is 
continued  by  other  student  researchers .  An  updated  FD  was  not  produced 
at  the  end  of  this  validation  effort  due  to  the  limited  number  of 
recommended  changes.  As  stated  earlier,  the  FD  was  updated  at  the  end 
of  this  project  and  is  contained  in  Appendix  K. 

Overall,  the  validation  effort  did  not  provide  the  authors  with 
the  type  of  detailed  recommendations  they  expected.  It  was  anticipated 
that  the  respondents  would  closely  scrutinize  the  FD  and  provide 
potential  low-level  requirements  for  the  major  ARMS  subsystems.  As  a 
result,  the  authors  were  forced  to  develop  the  low-level  requirements 
for  the  subsystems  based  on  the  validated  general  concepts  in  the  FD  and 
their  past  experience.  Section  three  of  Appendix  K  contains  the  product 
of  these  efforts. 

Rgs.earch  Qbjgctivg  Three  Results 

To  complete  this  objective,  the  authors  were  faced  with  three 
major  decisions.  The  first,  and  perhaps  most  important,  involved 
evaluating  the  alternative  approaches  for  meeting  the  requirements 
validated  in  research  objective  two.  Given  the  decision  to  pursue 
prototyping,  the  remaining  two  decisions  centered  on  the  selection  of 
specific  requirements  for  automation  and  the  prototype's  target 
architecture.  The  results  of  these  activities  are  summarized  in  the 
subparagraphs  that  follow. 

Evaluation  Alternatives .  Once  the  requirements  for  ARMS  were 
validated,  the  authors  needed  to  determine  the  best  course  of  action  to 
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pursue.  The  first  decision  centered  on  the  need  to  determine  if  further 
action  was  required.  Three  primary  alternatives  were  evaluated  and  are 
explained  in  this  section. 

The  first  alternative  was  to  do  nothing.  In  this  case,  the 
existing  methods  for  topic  selection,  research  product  reuse,  and 
research  management  would  have  to  be  considered  satisfactory.  The 
selection  of  this  alternative  would  have  canceled  the  need  for 
completing  the  remaining  objectives  and  led  to  an  early  completion  of 
this  study.  Based  on  the  encouragement  received  from  the  DE  and  LS 
research  directors  to  pursue  improvements  in  these  areas,  this 
alternative  was  not  selected. 

The  second  alternative  was  to  modify  an  existing  system.  This 
alternative  required  the  authors  to  examine  the  feasibility  of  modifying 
such  svstems  as  the  AFIT  Integrated  Library  System  (ILS)  or  Defense 
Techn.’ cal  Information  Center  (DTIC)  database  to  include  the  capabilities 
defined  in  the  ARMS  functional  description  (FD) .  This  option  was 
likewise  disregarded  since  these  and  many  other  systems  in  library  are 
commeicial  products  whose  changes  are  not  controlled  by  AFIT.  The 
effort  to  modify  one  of  these  products  could  have  been  contracted 
through  the  appropriate  manufacturer.  However,  this  option  was 
considered  cost -prohibitive  at  that  time  because  the  concepts  underlying 
the  AI-MS  implementation  were  as  yet  untested. 

The  final  alternative  was  to  develop  a  prototype.  This  option 
called  for  the  development  of  a  limited  system  to  evaluate  the 
underlying  concepts  of  the  ARMS  and  determine  the  desirability  of  such  a 
system.  The  authors'  past  experience  with  information  system 
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development,  along  with  the  support  offered  by  the  LS  research  director, 


were  key  factors  that  led  to  the  selection  of  this  alternative. 

Automation  Requirements  Selection.  The  development  of  a  prototype 
that  incorporated  all  of  the  requirements  contained  in  Appendix  K, 
Section  3,  would  have  been  too  great  an  effort  to  accomplish  under  the 
time  constraint  for  this  study.  Therefore,  the  requirements  for  each  of 
the  ARMS'  four  subsystems  were  pared  down  to  a  feasible,  but 
representative,  subset  for  implementation  in  the  prototype.  Special 
emphasis  was  placed  on  including  capabilities  that  would  permit 
evaluators  to  assess  the  potential  usefulness  of  a  production  quality 
ARMS.  The  detailed  requirements  selected  and  subsequently  implemented 
in  each  subsystem  are  delineated  in  Table  4-1. 


Table  4-1 


IMPLEMENTED  SUBSYSTEM  REQUIREMENTS  FOR  INITIAL  PROTOTYPE  ARMS 


SUBSYSTEM 

APPLICABLE  ARMS  FD  PARAGRAPHS 

Research  Topic  Selection 

3. 2. 2. 1.1  subparagraphs  A,  G,  and  I; 

3. 2. 2. 1.2. A;  and  3. 2. 2. 1.3 

Research  Products  Reuse 

3. 2. 2. 2.1. A  and  3. 2. 2. 2. 2 

Research  Management 

3. 2. 2. 3.1  subparagraphs  C,  D,  and  E;  and 

3. 2. 2. 3. 2 

Database  Administration 

3 . 2 . 2 . 4 . 1  and  3 . 2 . 2 . 4 . 2 

Computing  R.e.50urggg  Evaluation  ajld  Target  Architecture  Selection. 
The  next  task  was  to  choose  the  development  system  (hardware 
architecture  and  software)  for  the  prototype.  Three  common-user 
computing  system  architectures  were  examined  during  this  effort.  The 
first  was  the  VAX  Cluster,  which  was  comprised  of  four  Digital  Electric 
Corporation  (DEC)  mainframes.  The  primary  functions  and  software 
support  provided  by  these  mainframes  included;  student  file  storage. 
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electronic  mail  services,  administrative  program  applications,  database 
management  system  development  (using  the  ORACLE (TM)  Relational  Database 
Management  System) ,  and  a  variety  of  commercially  developed  packages . 

Two  UNIX  operating  system-based  resources  con^rised  the  next 
hardware  architecture  evaluated  during  this  study.  The  first  system, 
nicknamed  PHANTOM,  runs  the  Q-Office(TM)  software  suite.  It  provides 
user  service  functions  such  as  electronic  mail,  bulletin  board, 
electronic  calculator,  and  several  other  office  automation  capabilities. 
The  second  system  was  the  EN  graphics  workstation  laboratory,  nicknamed 
SCGRAPH.  The  laboratory's  workstations  host  a  wide  variety  of 
graphically-based  software  packages  Lnat  support  EN's  education, 
research,  and  administrative  programs.  At  the  time  of  this  study, 
neither  of  the  UNIX-based  systems  provided  the  capability  to  develop  a 
multi-user  database  management  system  like  the  ARMS. 

The  personal  computer  (PC)  local  area  networks  (LANs)  located 
throughout  AFIT  comprised  the  final  architecture  examined  during  this 
step.  The  PC  LANs  provide  students  with  a  diverse  set  of  commercial  and 
"in-house"  developed  software  for  meeting  their  educational  and  research 
needs.  Of  the  15  LANs  at  AFIT,  none  was  accessible  to  all  students. 
These  systems,  like  the  UNIX-based  systems,  also  lacked  the  capability 
to  develop  a  multi-user  database  management  system. 

The  results  described  above  led  to  the  authors'  decision  to 
develop  the  ARMS  prototype  on  the  VAX  Cluster  using  the  ORACLE (TM) 
Relational  Database  Management  System.  Specific  information  concerning 
the  software  configuration  used  to  develop  the  prototype  is  contained  in 
the  updated  ARMS  FD  (Appendix  K) ,  paragraph  5.2. 
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Research  Objective  Four  Results 

The  prototype's  design  and  development  took  approximately  four 
weeks  to  complete.  This  time  period  included  the  authors'  efforts  to 
learn  the  fundamentals  of  ORACLE'S  development  tools  and  to  draft  an 
initial  set  of  operating  instructions  for  the  prototype.  A  description 
of  the  results  of  this  objective  is  presented  below. 

ARMS  Design  and  Development .  The  design  and  development  of  the 
prototype  followed  a  systematic  approach  that  began  by  modeling  several 
aspects  of  the  current  research  environment.  A  review  of  the  specific 
inputs  and  outputs  of  the  current  system  yielded  a  list  of  "objects." 
Theses,  students,  advisors,  topics,  sponsors,  and  products  (also 
referred  to  as  components)  comprised  the  list  of  objects  and  each  became 
a  candidate  record  type.  The  interactions  between  these  objects  are 
illustrated  in  the  context  diagram  in  Figure  4-1. 

Each  object  was  then  examined  to  determine  its  defining 
characteristics  or,  in  the  information  system  terminology  presented 
earlier,  its  data  items.  Certain  special  characteristics  were  derived 
from  the  requirements  listed  in  the  FD.  For  instance,  several 
requirements  implied  the  need  for  categorizing  a  thesis  as  ongoing, 
continuing,  award-winning,  or  sponsored.  Control  data  items  for  all  of 
these  conditions  were  embedded  into  the  design  of  the  thesis  record 
type.  Many  general  characteristics  for  each  record  type  were  equally 
easy  to  define.  As  an  example,  the  advisor  and  student  record  types 
both  relate  to  people  and  have  data  items  for  first  name,  last  name, 
middle  initial,  and  rank.  A  detailed  data  dictionary  containing  a 
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Figure  4-1.  Context  Diagram  of  the  Current  AFIT  Research  Environment 


listing  of  each  record  type  (also  known  as  a  table),  its  purpose,  and 
its  component  data  items  is  provided  in  Attachment  1  of  Appendix  K. 

To  manage  the  development  of  the  prototype,  the  authors  divided 
the  system  into  logical  subsystems .  This  provided  them  with  a  benchmark 
for  gauging  completion  status  and  using  standardized  screen  displays 
across  different  options  within  the  same  subsystem.  The  three 
subsystems  (Res''‘arch  Topic  Selection  Subsystem  (RTSS),  Research  Products 
Reuse  Subsystem  (RPRS) ,  and  Research  Management  Subsystem  (RMS) ) 
originally  planned  in  the  initial  FD  (Appendix  C)  were  augmented  by  an 
additional  subsystem  to  manage  database  administration  functions .  This 
fourth  subsystem  was  aptly  named  the  Database  Administration  Subsystem 
(DAS) . 
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The  next  step  involved  the  development  of  a  menu  structure  that 


incorporated  each  subsystem  and  its  associated  functions.  This  effort 
was  guided  by  the  following  general  descriptions  of  each  subsystem: 

RTSS  -  Through  the  categorization  of  theses  and  automation  of  the 
current  research  topics  book,  the  RTSS ' s  goal  is  to  provide 
student  researchers  with  the  capability  to  review  available 
information  in  a  more  focused  and  expedient  manner.  The 
on-line  information  contained  in  the  RTSS's  tables  allows 
researchers  to  review  the  complete  abstract  of  an  AFIT 
thesis  and  assists  in  determining  if  a  more  detailed  review 
of  the  document  is  warranted.  Four  categories  of  theses 
and  automated  research  requests  can  be  queried  and  reviewed 
based  on  a  variety  of  criteria . 

RPRS  -  The  RPRS  represents  an  adaptation  of  the  'software  reuse' 
concept,  which  is  defined  as  the  use  of  previously 
developed  and/or  acquired  software  components  (such  as 
source  code  modules,  design  descriptions,  documentation, 
and  so  on)  in  a  new  development  project.  The  application 
of  this  technique  to  the  thesis  yields  several  potential 
components  for  reuse.  Currently,  the  process  of  locating 
such  items  is  very  tedious  and  time-consuming  since  only 
the  thesis  document  is  cataloged.  The  RPRS  provides  the 
framework  for  cataloging  research  components  and  allows  for 
the  on-line  storage  of  an  abstract  describing  the 
component,  and  in  some  cases,  an  electronic  copy  of  the 
component  itself. 

RMS  -  The  RMS  is  designed  to  provide  a  convenient  source  of 
management  information  concerning  the  AFIT/LS  student 
research  program.  The  initial  capabilities  of  this 
subsystem  include  the  ability  to  query  and  review 
information  concerning  continuing  research  studies, 
research  sponsorship,  and  thesis  advisor  interests/ 
qualifications . 

DAS  -  This  subsystem  is  designed  to  provide  personnel  assigned 
database  administration  responsibilities  with  the 
capabilities  to  perform  their  job.  Two  primary  sets  of 
activities  may  be  done  in  this  subsystem:  record 
manipulation  and  special  queries . 

Appendix  F  examines  all  of  the  menus  developed  during  this  phase  and 
explains  how  each  subsystem  performs  its  required  functions. 
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Three  types  of  screen  displays  were  then  developed  to  meet  the 
autonvation  requirements  selected  during  research  objective  three.  The 
"query"  screen,  which  provided  the  user  with  a  "friendly"  interface  to 
find  records  of  interest,  was  the  first  type  of  screen  developed.  The 
next  step  was  to  design  the  screens  that  would  display  information 
records  retrieved  by  a  user-provided  query.  The  final  step  in  this 
process  involved  providing  the  capability  to  view  long  text  files,  such 
as  abstracts  and  electronic  copies  of  components.  Appendix  F  should  be 
reviewed  for  more  information  about,  the  screen  layouts  and  procedures 
for  using  them.  In  addition.  Attachment  2  of  Appendix  K  should  be 
consulted  for  details  about  the  ORACLE  SQLFORMS  files  that  contain  the 
screen  display  source  code . 

A  limited  help  system  was  implemented  with  this  version  of  the 
prototype.  A  user  can  get  help  from  the  system  by  pressing  'O'  on  the 
keypad  (<KP0>)  during  any  menu,  query,  or  information  record  display. 
Pressing  <KP0>  when  a  menu  screen  is  displayed  provides  the  user  with 
information  about  menu  options,  while  pressing  <KP0>  during  the  display 
of  query  or  information  records  presents  a  layout  of  active  keys  for  use 
within  the  current  function.  Additional  help  is  provided  on  many  of  the 
screens  in  the  form  of  "text  boxes"  and  one-line  messages  that  appear  in 
the  inverse  video  at  the  bottom  of  most  screens.  The  ARMS  User's  Guide 
(Appendix  F)  contains  some  specific  examples  of  the  help  information 
provided  by  the  current  prototype  system. 

Overall,  the  system's  design  was  guided  by  the  goal  of  integrating 
the  plethora  of  information  available  within  a  research  program.  while 
the  prototype  built  and  evaluated  during  this  study  was  somewhat 


limited,  it  does  provide  a  modular  framework  that  can  be  expanded.  The 
context  diagram  in  Figure  4-2  shows  how  the  ARMS  centralizes  and 
potentially  streamlines  the  flow  of  research  information.  .As  noted 
several  times  above,  the  interested  reader  is  encouraged  to  review 
Appendices  F  and  K  to  gain  a  better  understanding  of  the  prototype's 
design  and  operation. 
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User ' s  Gu ide  Development .  In  conjunction  with  the  development  of 


the  prototype  system,  the  authors  drafted  a  user's  guide  (Appendix  F) 
for  use  by  personnel  participating  in  the  operational  test.  The  guide 
begins  with  an  introduction  to  the  system  and  contains  specific 
instructions  on  how  to  access,  operate,  and  exit  the  system.  It  also 
contains  specific  examples  that  lead  an  ARfJS  user  through  queries  in  the 
research  topic  selection,  research  products  reuse,  and  research 
management  subsystems .  The  guide  does  not  cover  procedures  for 
operating  the  database  administration  subsystem  since  access  to  it  was 
limited  to  the  authors  for  development  and  testing  purposes. 

Research  Objective  Five  Results 

Once  the  prototype  ARMS  was  built,  the  next  series  of  steps 
involved  preparing  for  and  conducting  an  operational  test  and 
evaluation.  In  completing  this  objective,  the  authors  populated  the 
prototype,  developed  an  evaluation  instrument,  and  conducted  the  test 
using  the  approach  in  Chapter  III. 

Prototype  System  Population .  This  step  involved  populating  tlie 
prototype  ARMS  with  an  initial  data  set.  Since  most  of  the  data  were 
derived  from  theses,  the  authors  recognized  the  need  for  qualitative 
criteria  to  select  the  documents  for  input  into  the  system.  It  was 
decided  that  award-winning  LS  theses  from  the  past  three  years  would  be 
used  as  the  primary  benchmark,  since  these  studies  had  been  judged  by 
the  faculty  to  be  of  superior  quality.  This  criteria  should  be  expanded 
for  future  prototyping  efforts. 
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Information  from  a  total  of  seventeen  theses  was  placed  into  the 
ARMS  thesis,  student,  advisor,  sponsor,  and  component  tables.  Fifteen 
of  the  seventeen  selected  theses  met  the  criteria  listed  in  the  above 
paragraph.  One  of  the  additional  theses  was  selected  because  it  was  the 
source  of  a  component  reused  by  one  of  the  award-winning  theses .  The 
final  thesis  was  one  that  was  needed  to  demonstrate  the  ARMS  capability 
to  provide  ongoing  thesis  information.  The  text  file  abstracts  for  the 
completed  theses  were  based  on  the  abstracts  contained  in  each  document . 
A  draft  abstract  was  developed  for  the  ongoing  thesis  effort. 

A  total  of  sixteen  components  were  derived  from  the  seventeen 
theses  documented  in  the  database.  Component  records  and  abstracts  were 
developed  by  reviewing  the  applicable  thesis  text  portions  and 
extracting  details.  Seven  of  the  sixteen  components  were  reproduced  for 
electronic  storage  and  access  through  the  ARMS  RPRS .  The  remaining 
components  were  not  entered  because  they  were  either  too  large  or 
complex  for  inclusion  in  this  version  of  the  prototype.  Table  4-2 
provides  a  summary  of  the  component  types  input  into  the  ARMS. 


Table  4-2 

BREAKDOWN  OF  COMPONENTS  TAKEN  FROM  THESES 


COMPONENT  TYPE 

#  CATALOGED  IN 

THE  DATABASE 

#  ELECTRONICALLY 

ARCHIVED 

Documentation 

1 

0 

Questionnaire 

3 

2 

Survey 

5 

3 

Interview 

1 

1 

Statistical  Models 

6 

1 

Data  on  possible  thesis  topics  available  to  incoming  LS  students 
was  also  included  in  the  database.  Nineteen  topics  were  randomly 
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selected  from  the  LS  Thesis  Topics  Book  located  in  the  library.  The 
information  used  to  complete  each  topic  record  was  gathered  solely  from 
the  applicable  new  research  request  forms.  Seven  of  the  selected  topics 
were  generated  by  AFIT  faculty,  while  the  remaining  twelve  w’ere  received 
from  other  DoD  agencies. 

Evaluation  Instrument  Development .  The  questionnaire  used  to 
evaluate  the  prototype  ARMS  was  adapted  from  one  developed  by  Captain 
Deanna  McMurry  for  an  AFIT  thesis  completed  in  1990  (McMurry,  1990:90- 
92).  McMurry's  questionnaire  contained  twenty  questions  that  were  used 
to  evaluate  the  technical  adequacy  and  suitability  of  a  prototype 
hypertext  office  reference  system.  Nine  questions  (numbers  1,  6a,  8,  9, 
12,  13,  18,  19,  and  20)  were  selected  from  the  original  set  and  modified 
to  construct  the  evaluation  instrument  in  Appendix  E. 

The  evaluation  instrument's  first  and  last  questions  provided  the 
authors  with  a  means  of  evaluating  each  respondent's  experience  before 
the  test  and  overall  use  of  the  prototype.  Questions  two  through  five 
addressed  the  user  friendliness  of  the  ARMS  in  terms  of  its  on-line  help 
and  ease  of  use  characteristics.  The  fifth  and  sixth  questions  allowed 
the  test  participants  to  subjectively  assess  the  suitability  of  the  ARMS 
and  its  potential  to  improve  the  research  process.  The  remaining  two 
questions  provided  the  evaluators  with  the  opportunity  to  annotate  what 
they  liked  about  the  system  and  what  they  felt  needed  improvement.  A 
space  was  also  supplied  to  write  additional  comments  about  the  ARMS  or 
the  project  in  general. 

Operational  Test  Conduct .  The  ARMS  operational  test  was  conducted 
in  two  phases.  Phase  one  was  conducted  with  twenty -nine  newly  arrived 
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students  in  the  class  of  1993,  while  the  phase  two  included  eighteen 
students  in  the  class  of  1992  and  11  LS  faculty  members.  These  sample 
sizes  represented  fifteen  percent  of  the  class  of  1993,  eighteen  percent 
of  the  class  of  1992,  and  six  percent  of  the  LS  faculty,  respectively. 

The  evaluation  was  conducted  within  the  LS  computer  laboratories 
and  was  guided  by  a  forty- five  minute  project  orientation  and  system 
demonstration.  The  first  fifteen  minutes  of  each  test  were  used  to 
present  an  overview  of  the  project,  the  prototype's  major  functions,  and 
the  evaluation  instrument.  The  remaining  thirty  minutes  were  spent 
demonstrating  the  prototype  ARMS'  capabilities.  During  this  period,  the 
evaluators  were  encouraged  to  follow  along  on  their  personal  computers . 
The  example  queries  performed  by  the  demonstrator  are  listed  in  the 
draft  ARMS  user's  guide  (Appendix  F) .  Following  the  demonstration, 
evaluators  were  permitted  to  perform  individual  queries  and  complete  the 
prototype  ARMS  evaluation  questionnaire .  The  results  of  the  test  are 
discussed  in  the  next  section. 

Research  Objective  Results 

The  two- phased  operational  test  yielded  the  raw  results  contained 
in  Appendices  G,  H,  I,  and  J.  This  section  discusses  some  of  the 
significant  results  gained  through  an  analysis  of  this  data.  It 
specifically  addresses  the  technical  characteristics  of  the  current 
prototype  and  its  overall  suitability  to  meet  the  needs  expressed  in  the 
ARMS  FD. 

Technical  Adequacy  Assessment .  The  technical  adequacy  assessment 
for  this  version  of  the  prototype  centered  on  the  system's  user 
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friendliness  and  overall  performance  characteristics.  Evaluator 


responses  to  questions  two,  three,  four,  seven,  and  eight  in  the 
prototype  ARMS  evaluation  questionnaire  (Appendix  E)  provided  the 
necessary  information  to  analyze  these  items . 

A  system's  "user  friendliness"  is  often  difficult  to  judge.  Some 
basic  attributes  of  such  systems  include  the  availability  of  on-screen 
help,  programmed  function  mapping  to  special  keys,  and  error  messages 
that  describe  what  went  wrong  ( Pfaf fenberger,  1990:464).  An  analysis  of 
questions  two,  three,  and  four  showed  that  the  prototype  ARMS  met  each 
of  these  needs  through  the  screen  and  form  designs  described  above. 

The  menu  help  screens  were  highly  rated  by  all  three  samples  with 
satisfaction  ratings  of  eighty-six  percent  by  the  new  students,  eighty 
percent  by  the  faculty,  and  seventy-eight  percent  by  the  current 
students.  In  addition.  Table  4-3  reflects  that  the  subsystem-specific 
help  facilities  (which  included  context-sensitive  help,  function  key 
mapping  information,  and  error  messages)  received  similar  ratings. 
Although  the  ratings  for  the  faculty  sample  were  relatively  lower  for 
this  question  three,  there  were  no  apparent  reasons  for  these  deviations 
provided  in  the  written  comments  on  the  evaluation  forms . 


Table  4-3 


EVALUATION  QUESTIONNAIRE  RESULTS  FOR  QUESTION  THREE 


SAMPLE 

RTSS 

RPRS 

RMS 

New  Students 

83% 

79% 

Not  evaluated 

Current  Students 

89% 

94% 

89% 

Faculty 

80% 

60% 

70% 
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The  questionnaire  results  for  question  four  strongly  support  the 
"user  friendliness"  suggested  above.  Table  4-4  indicates  that  all  three 
samples  rated  the  subsystems  as  easy  to  learn  and  use . 


Table  4-4 

EVALUATION  QUESTIONNAIRE  RESULTS  FOR  QUESTION  FOUR 


SAMPLE 

RTSS 

RPRS 

RMS 

New  Students 

93% 

87% 

Not  evaluated 

Current  Students 

94% 

83% 

88% 

Faculty 

80% 

70% 

60% 

In  evaluating  the  responses  to  questions  seven  and  eight,  two 
other  areas  stood  out  as  "well-liked"  by  all  three  samples.  The  screen 
displays  garnered  the  approval  of  eighty  percent  of  the  faculty, 
seventy-eight  percent  of  the  current  students,  and  seventy- two  percent 
of  the  new  students,  while  the  functions  performed  by  the  subsystems 
were  favored  by  90  percent  of  the  current  students,  83  percent  of  the 
new  students,  and  60  percent  of  the  faculty. 

On  the  negative  side,  evaluator  responses  to  questions  seven  and 
eight  suggested  improvements  need  to  be  made  in  the  areas  of  processing 
speed  and  data  breadth.  The  first  improvement  item  was  the  result  of 
some  VAX  Cluster  system  problems  which  caused  interruptions  during 
several  demonstration  sessions.  This  led  several  evaluators  to  suggest 
re-hosting  of  the  ARMS  to  the  LS  PC  LAN.  The  second  improvement  area 
was  a  factor  induced  by  the  authors'  attempt  to  build  such  a  large 
system  in  a  short  time  period.  Developing  a  more  extensive  data  set  for 
the  initial  prototype  would  have  required  trade-offs  in  other  areas  of 
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the  ARMS  development  and  testing.  To  avoid  this  situation  in  future 


research  efforts  to  improve  the  prototype,  researchers  should  avoid 
simultaneously  making  many  extensive  enhancements . 


Suitability  Assessment .  The  suitability  assessment  for  this 
version  of  the  prototype  was  based  on  the  subjective  views  of  the 
operational  test  evaluators.  In  particular,  the  responses  to  questions 
five  and  six  in  the  prototype  ARMS  evaluation  questionnaire  (Appendix  E) 
provided  the  necessary  information  to  perform  this  analysis. 

Table  4-5 


EVALUATION  QUESTIONNAIRE  RESULTS  FOR  QUESTIONS  FIVE  AND  SIX 


OUESTION/SUBSYSTEM 

NEW  STUDENTS 

CURRENT  STUDENTS 

LS  FACULTY 

# 5/RTSS 

97% 

95% 

70% 

#5/RPRS 

96% 

95% 

70% 

#5 /RMS 

Not  evaluated 

83% 

80% 

# 6/RTSS 

100% 

100% 

50% 

#6/RPRS 

100% 

94% 

50% 

#6 /RMS 

Not  evaluated 

94% 

60% 

The  results  of  evaluation  questions  five  and  six  are  summarized  in 
Table  4-5.  The  two  student  samples  expressed  almost  universal  agreement 
concerning  the  need  for  the  ARMS  RTSS  and  RPRS .  Interestingly,  the 
faculty  ratings  for  these  questions  was  much  lower  than  expected.  A 
closer  evaluation  of  the  responses  to  these  questions  indicated  that 
many  faculty  members  elected  to  circle  the  'neutral'  or  'not  evaluated' 
options.  This  might  indicate  that  the  phrasing  of  these  questions 
should  have  been  adjusted  for  the  faculty  population.  As  written,  the 
questions  specifically  apply  to  the  student  researcher's  role  in  the 
research  process . 
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Overall,  the  ARMS  prototype  operational  test  demonstrated  the 


desirability  of  having  an  automated  tool  that  performs  the  functions 
described  in  the  FD .  Further  research  will  have  to  be  conducted  before 
an  informed  decision  can  be  made  as  to  whether  or  not  it  is  reasonable 
to  implement  a  production-quality  system.  Accordingly,  a  number  of 
further  research  recommendations  are  provided  in  Chapter  V. 
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Summary 


Y.  Sumn^ry.  Conclusions,  and  Recommendations 

The  underlying  impetus  of  this  study  was  to  enhance  student 
researcher  productivity  through  the  use  of  automation.  To  scope  this 
general  issue  down  to  a  manageable  research  project,  the  authors 
performed  a  literature  review  and  conducted  an  examination  of  the 
current  academic  research  environment.  These  efforts  resulted  in  the 
selection  and  further  examination  of  two  areas  of  difficulty  that 
inherently  impact  student  researcher  productivity- -research  topic 
selection  and  research  product  reuse.  A  third  area  of  the  research 
domain,  research  management,  was  also  investigated  but  to  a  lesser 
degree  than  the  first  two  areas. 

The  modeling  and  subsequent  implementation  of  the  three  selected 
areas  into  a  "proof -of -concept"  prototype  information  system  were  done 
using  a  hybrid  software  development  life  cycle  model.  An  initial 
operational  test  of  the  developed  prototype  ARMS  indicated  strong 
support  for  the  conceptual  basis  of  the  system  and  provided  many 
recommendations  for  improving  it.  The  time  limitation  placed  on  this 
study  did  not  permit  the  authors  to  examine  several  key  issues  that 
should  be  considered  before  an  informed  implementation  decision  is  made. 
These  issues  are  discussed  later  in  this  chapter  as  part  of  the  section 
on  future  research  recommendations. 

Conclusions 

The  accomplishment  of  this  study  yielded  two  groups  of 
conclusions.  The  first  group  is  of  a  general  nature  and  reflects  the 
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insights  gained  during  the  execution  of  this  study's  methodology.  The 
second  group  includes  what  the  authors  perceive  as  specific 
contributions  to  research. 

General .  A  unique  approach  to  system  development  was  employed  to 
complete  this  research.  As  described  in  Chapters  I  and  III,  the  authors 
generally  patterned  the  study's  seven  research  objectives  after 
milestones  in  a  traditional  system  development  life  cycle  with  one 
exception- -the  planned  final  product  was  an  initial  prototype  vice  a 
production-quality  system.  To  address  the  potential  need  for  evolving 
the  prototype  into  a  well-defined,  production-quality  system,  the 
authors  then  adapted  and  used  a  meta -model  called  the  spiral  life  cycle 
model  for  system  development  (Boehm,  1988:64).  The  resultant  model  is  a 
hybrid  of  the  traditional  and  spiral  models  that  not  only  supplied  the 
initial  framework  for  conducting  this  study,  but  established  an  approach 
that  follow-on  researchers  can  use  to  iteratively  refine  the  prototype. 

The  use  of  a  functional  description  (FD)  to  formally  document  and 
validate  system  requirements  represented  another  unique  aspect  of  this 
research.  A  review  of  recent  AFIT  thesis  projects  revealed  that  this 
approach  has  been  infrequently  applied  by  other  researchers  developing 
automated  systems.  However,  the  authors  felt  compelled  to  provide  a 
document  that  would  encapsulate  their  efforts  and  serve  as  a  common 
baseline  through  subsequent  development  phases  of  the  ARMS.  As  stated 
in  Chapter  IV,  the  FD  validation  effort  did  not  produce  the  expected 
level  of  user  participation.  This  may  have  been  due  to  the  inherent 
difficulty  of  describing  an  abstract  entity  like  software  in 
nontechnical  terms.  Despite  its  minimal  early  success,  the  FD  should 
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continue  to  be  updated  and  used  in  follow-on  studies  to  document  and 
validate  the  ARMS  requirements . 

Research  Contributions .  A  production-quality  system  that  is 
similar  to  the  prototype  produced  by  this  study  has  the  potential  to 
provide  many  potential  benefits  in  the  areas  of  research  topic 
selection,  research  products  reuse,  and  research  management.  A  brief 
discussion  of  the  conceptual  contributions  that  each  subsystem  makes  to 
researcher  productivity  and  process  improvement  is  provided  below. 

Research  Topic  .’^election  Subsystem  rRTSS^  .  The  RTSS 
provides  an  additional  automated  method  for  reviewing  information  on 
"past"  AFIT  theses.  It  differs  from  current  systems,  such  as  the 
Integrated  Library  System  (ILS)  and  Defense  Technical  Information  Center 
(DTIC)  catalog  system,  in  three  ways;  (1)  it  provides  a  more  detailed 
thesis  information  record;  (2)  it  presents  a  textual  abstract  of 
unlimited  length;  and  (3)  it  allows  researchers  to  review  theses  that 
have  been  categorized  as  "continuing"  or  "sponsored"  studies.  These 
capabilities  provide  increased  information  to  researchers  and 
potentially  assist  them  in  determining  if  a  further  review  of  a  thesis 
document  is  warranted. 

The  RTSS  also  allows  researchers  to  review  information  and 
abstracts  for  theses  that  are  still  in  progress  when  they  are  beginning 
their  search  for  a  thesis  topic.  Currently,  researchers  looking  for  a 
study  that  could  be  continued  are  dependent  on  the  advisors  and  authors 
of  ongoing  research  for  information.  As  discussed  in  Chapter  II,  newly 
arrived  student  researchers  within  LS  face  a  dilemma  when  they  attempt 
to  obtain  and  use  this  information  to  fulfill  their  research  paper 
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requirements  for  the  COMM  687  course.  The  RTSS  bridges  the  current 
information  gap  concerning  ongoing  studies  and  allows  new  student 
researchers  to  review  and  evaluate  potential  topics  for  continued  study . 
In  essence,  they  can  begin  the  process  of  topic  selection  earlier  in 
their  graduate  programs  than  the  "unofficial"  September  availability 
date  of  thesis  advisors. 

The  RTSS  also  automates  the  current  research  topics  book.  This 
new  resource  provides  a  more  organized  and  traceable  method  of  managing 
the  topics  generated  by  the  faculty  and  received  from  other  USAF  and  DoD 
organizations.  In  addition,  a  production-quality  RTSS  would 
theoretically  furnish  around-the-clock  access  (through  the  AFITNET 
computer  network)  to  new  research  requests  and  allow  students  to  search 
for  a  thesis  topic  at  their  convenience. 

Research  Products  Reuse  Subsystem  (RPRS) .  The  RPRS  is 
possibly  the  most  innovative  aspect  of  the  prototype  ARMS.  As  described 
in  Chapters  I  and  II,  many  "reusable"  research  components  and  outputs 
are  buried  in  completed  theses.  The  current  version  of  the  RPRS 
represents  an  initial  capability  for  cataloging,  tracking,  and  managing 
these  products  so  they  can  be  located,  reviewed,  and  reused  in  new  or 
follow-on  thesis  efforts.  This  subsystem,  used  in  conjunction  with  the 
RTSS,  could  potentially  be  used  to  promote  the  desirable  goal  of 
increased  continuing  studies.  However,  several  policy  and  procedural 
details  concerning  the  maintenance  and  use  of  the  RPRS  need  to  be 
resolved  before  it  can  be  effectively  implemented. 

Research  Management  Subsystem  (RMS) .  The  time  constraints 
of  this  study  limited  the  RMS's  design  and  development  to  the 
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consideration  of  three  information  needs  within  the  research  management 
community.  In  its  current  form,  the  subsystem  pro^'^ides  users  with  the 
ability  to  record  and  review  continuing  studies  information,  research 
sponsorship  data,  and  thesis  advisor  qualifications.  Of  these  three 
areas,  only  one,  thesis  advisor  qualifications,  is  formally  monitored  in 
the  current  LS  research  program. 

Despite  its  current  primitive  state,  the  RMS  was  well - received 
during  the  operational  test.  Personnel  testing  the  system  voiced  many 
verbal  recommendations  on  how  to  expand  this  subsystem  but  did  not 
formally  provide  any  in  their  written  comments.  The  authors  feel  that 
future  improvements  to  this  subsystem  are  an  essential  aspect  of  making 
the  overall  ARMS  a  more  viable  tool  for  use  in  the  APIT  research 
environment . 

Recommendations 

The  authors  encountered  many  related  issues  that  could  not  be 
addressed  as  part  of  this  research.  Research  objective  seven  was 
established  and  completed  to  ensure  these  issues  were  available  for 
future  research.  As  described  in  Chapter  III,  this  objective  called  for 
the  accumulation,  documentation,  and  division  of  issues  into  two  main 
categories:  (1)  recommendations  related  to  follow-on  development  of  the 
prototype  system;  and  (2)  suggestions  for  corollary  studies. 

Follow-on  Development  ai  the  Prototype .  There  are  three  main 
sources  of  recommendations  for  follow-on  development  of  the  prototype. 
The  first  source  is  comprised  of  the  subsystem  requirements  delineated 
in  section  three  of  the  updated  FD  (Appendix  K) ,  excluding  the 


5-5 


paragraphs  listed  in  Table  4-1.  Table  4-1  contains  the  automation 
requirements  that  were  selected  for  implementation  in  the  initial 
prototype  during  research  objective  three.  The  two  remaining  sources  of 
prototype  enhancement  recommendations  are  the  contents  of  Appendix  D  and 
Appendix  J.  These  appendices  contain  summarized  written  comments  and 
recommendations  from  the  FD  validation  and  operational  test  efforts  that 
were  completed  as  part  of  research  objectives  two  and  five, 
respectively . 

In  addition  to  making  the  changes  .lecomm..  nded  in  the  above 

sources,  follow-on  research  studies  could  also  be  conducted  to: 

1.  Refine  the  ARMS  one  subsystem  at  a  time.  For  example,  the 
Research  Topic  Selection  Subsystem  could  be  considered  as  a 
stand-alone  system,  enhanced  accordingly,  and  then  implemented 
as  a  production-quality  system. 

2.  Extend  the  current  prototype  to  include  one  or  more  subsystems 
that  deal  with  faculty  research  program.  The  goal  of  such  a 
study  would  be  to  expand  the  conceptual  basis  of  the  current 
prototype  to  other  research  domain  areas . 

However,  before  proceeding  with  any  enhancements  to  the  current 

prototype,  some  consideration  should  be  given  to  completing  one  or  more 

of  the  corollary  studies  described  in  the  next  subsection. 

Corollary  Studies .  The  completion  of  this  exploratory  research 
project  signals  the  need  for  several  corollary  studies.  In  particular, 
the  relative  success  of  this  study's  prototyping  effort  needs  to  be 
considered  within  the  context  of  the  numerous  administrative  and  other 
factors  that  could  impact  its  successful  implementation.  Three  major 
corollary  studie.s  are  descrobed  below. 

Perform  a.  Cost-Benefit  Analysis .  The  aim  of  a  cost-benefit 
analysis  study  would  be  to  conclusively  examine  all  potential 
alternatives  for  meeting  the  requirements  in  the  ARMS  FD .  The  first 
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step  would  involve  determining  the  projected  costs  and  benefits  of  each 
alternative.  The  results  of  this  step  could  then  be  used  to  compare  the 
alternatives  and  select  the  best  course  of  action.  A  study  of  this 
nature  is  strongly  recommended  in  light  of  the  ongoing  efforts  to  trim 
the  military's  fiscal  and  personnel  resources.  The  ARMS  may  indeed 
represent  a  desirable  solution  that  APIT  cannot  afford  to  sustain. 

Develop  Qualitative  Criteria  for  Reuse  Components .  As 
discussed  in  Chapter  II,  one  major  obstacle  to  the  widespread 
utilization  of  software  reuse  is  the  lack  of  a  definitive  quality 
standard  for  components.  In  practice,  attempting  to  reuse  poorly 
designed  components  can  lead  to  serious  project  delays  and  negatively 
impact  the  system's  overall  quality.  The  subjectivity  involved  in 
evaluating  academic  work  could  pose  a  similar  problem  to  the  concept  of 
research  product  reuse.  The  aim  of  a  study  in  this  area  would  be  to 
develop  a  "consensus"  set  of  criteria  to  use  in  evaluating  items  before 
they  are  placed  in  the  Research  Products  Reuse  Subsystem. 

Investigate  Policy  Decisions  Required  to  Implement  the  ARM.S . 
A  multitude  of  policy  decisions  are  needed  before  a  production-quality 
ARMS  can  be  implemented.  Some  of  the  most  important  questions  that  need 
answers  include : 

1.  What  personnel  resources  are  available  to  maintain  and 
ascertain  the  system's  data  accuracy  and  currency? 

2.  Who  should  be  responsible  for  determining  if  a  research 
product  is  of  sufficient  quality  to  be  cataloged  in  the 
research  product  reuse  subsystem? 

3.  What  data  entry  responsibilities,  if  any,  should  be  delegated 
among  students,  thesis  advisors,  and  research  management 
personnel? 
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The  organization  and  operational  impact  sections  of  the  updated  FD 
(paragraphs  2. 4. 2.1  and  2. 4. 2. 2,  respectively)  provide  some  suggestions 
on  how  to  approach  these  questions,  but  they  are  not  conclusive.  Rather 
than  initiating  a  separate  study  to  address  the  above  concerns,  one  or 
more  of  these  questions  could  be  considered  during  the  conduct  of  the 
other  corollary  studies  listed  above. 
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The  personal  interviews  conducted  with  the  research  director  for 
each  AFIT  school  followed  the  format  listed  below.  in  an  effort  to 
facilitate  interviewee  preparation  and  feedback,  the  researchers  sent 
this  three-part  interview  format  and  a  short  abstract  describing  the 
project  to  each  research  director  one  week  before  the  scheduled 
interviews.  These  interviews  had  three  primary  goals: 

1.  to  gain  an  understanding  of  the  general  structure,  management 
philosophy,  and  overall  strengths  and  weaknesses  of  each 
school's  research  program; 

2.  to  present  the  basic  tenets  of  the  authors'  research  proposal 
and  obtain  general  feedback  about  the  project;  and 

3 .  to  solicit  recommendations  about  desired  requirements  for  what 
was  then  termed  the  research  products  reuse  program. 

The  questions  listed  below  represent  the  minimal  set  deemed 
necessary  to  meet  the  above  goals.  Many  other  potential  questions  could 
have  been  asked  if  a  more  exhaustive  study  of  the  environment  was 
needed.  Actually,  the  research  directors  provided  more  information  in 
answering  these  and  unplanned  follow-up  questions  than  the  authors 
needed  to  meet  their  goals  for  the  interviews.  Portions  of  the 
information  derived  from  the  interviews  are  recorded  in  Chapters  II  and 
IV,  and  Appendix  B. 

It  should  be  noted  that  this  structured  interview  was  developed  at  a 
time  when  the  authors  were  still  fleshing  out  the  details  for  their 
study.  As  described  in  Chapters  II  and  IV,  the  results  of  this 
interview  changed  the  scope  of  this  research. 


PART  1.  GENERAL  QUESTIONS 

A.  What  is  the  goal  of  research  within  your  school? 

B.  Who  is  involved  in  the  research  process?  What  are  their 
responsibilities? 

C.  What  established  timelines/milestones  guide  the  thesis  research 
program?  Are  they  formally  published  and  made  known  to  the 
student  researchers? 

D.  What  types  of  external  support/sponsorship  are  received? 

P.MT  JJU  MANAGEMEiO:  QUESTIONS 

A.  How  are  certain  types  of  research  promoted  within  your  school? 

1.  How  much  of  your  school's  research  could  be  considered 
theory -building? 


2.  How  much  of  ^our  school's  research  could  be  considered 
theory  testing? 


3.  What  are  the  typical  focus  areas  of  your  school's  research? 

4 .  How  are  continuing  studies  promoted  and  managed  within  your 
school? 

B.  How  is  research  evaluated  in  terms  of  quality  and  depth? 

1.  Are  there  any  management  indicators  used  to  track: 
continuing  studies,  demand  for  faculty  consultation  in  key 
research  areas,  or  sponsorship  trends? 

2.  If  there  are  indicators,  are  they  monitored  by  manual  or 
automated  systems? 

3 .  In  your  opinion,  what  are  the  relative  strengths  and 
weaknesses  of  your  school's  research  program? 

4.  Are  there  any  on-going  efforts  to  improve  your  school's 
research  program? 

PART  III ,  PROPOSAL  PRESENTATION/FEEDBACK 
A.  Proposal  Outline 

1.  General  Issue:  The  long-standing  need  for  quality  and 
utility  in  research  is  an  issue  that  perpetually  receives 
high-level  interest  within  the  academic,  business,  and 
government  communities.  Questions  about  how  to  establish 
and  promote  research  programs  with  these  attributes  have 
guided  many  past  and  current  initiatives.  However,  there  is 
not  a  general  consensus  on  a  specific  method  to  accomplish 
these  tasks . 

2.  Specific  Research  Goal:  The  goal  of  this  research  is  to 
design,  develop,  and  test  a  prototype  information  system 
that  will  support  the  implementation  of  a  research  products 
reuse  program  within  the  Air  Force  Institute  of  Technology 
(AFIT)  School  of  Systems  and  Logistics  (LS) . 

3.  Methodology/Research  Objectives: 

a .  Describe  the  AFIT  research  environment . 

(1)  Interview  research  directors  for  each  AFIT  school. 

(2)  Investigate  and  document  major  research  resources 
available  to  AFIT  student  researchers. 

b.  Define  and  validate  the  requirements  for  an  AFIT 
research  products  reuse  program. 

(1)  Develop  a  proposed  list  of  requirements  using  the 
interview  results  and  researchers '  experiences . 

(2)  Design  a  requirements  validation  document  for 
AFIT-wide  faculty  review  and  distribute  it. 

(3)  Analyze  validation  results  and  update  requirements 
list . 

c.  Determine  the  specific  requirements  for  automation  and 
select  the  prototype's  target  architecture. 

d.  Design/develop  the  prototype  system  and  operating 
instructions  for  test  users . 


A-2 


e.  Prepare  and  conduct  an  operational  test  for  the 

prototype  system. 

(1)  Populate  the  system  with  sample  research  products 
(surveys,  questionnaires,  statistical  models,  etc.) 
that  could  be  used  wholly,  or  modified  and  then 
reused  in  future  research  studies. 

(2)  Select  or  develop  an  evaluation  instrument. 

(3)  Conduct  tests  with  two  random  samples;  one 
comprised  of  students  and  the  other  faculty. 

f.  Analyze  operational  test  results. 

(1)  Assess  technical  adequacy  of  the  prototype  system. 

(2)  Assess  the  prototype's  suitability  and  potential 
for  contributing  to  the  AFIT  research  environment . 

g.  Develop  recommended  path  for  follow-on  research. 

(1)  Provide  suggestions  for  follow-on  development  of 
the  prototype  system. 

(2)  Propose  corollary  studies  to  fulfill  the  require¬ 
ments  deemed  unresolvable  through  automation,  such 
as  the  policy  structure  needed  to  successfully 
implement  the  system. 


B.  Feedback  Questions 

1.  What  are  your  general  impressions  of  the  proposal? 

2.  What  recommendations  do  you  have  about  the  requirements  for 
the  research  products  reuse  program? 

3.  Would  you  be  interested  in  assisting  us  with  this  study? 

4.  Would  you  be  interested  in  evaluating  the  final  product? 
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Appendix  £j.  q1  Rgsgargh  Pirggtcr  Intgrxi..gw  Results 


The  matrix  below  provides  the  major  results  derived  from  the 
personal  interviews  conducted  with  the  research  director  for  each  AFIT 
school.  The  selected  areas  of  interest  listed  in  the  first  column  were 
used  to  encapsulate  answers  from  several  questions .  A  more  detailed 
discussion  of  results  that  pertain  to  the  revised  scope  of  this  study 
are  presented  in  Chapters  II  and  IV. 


AREA 

DE 

EN 

LS 

TYPE  OF  RESEARCH 

Mostly  applied; 

10%  theory 

Mostly  applied; 
faculty/sponsor - 
driven 

Mostly  applied; 
10-20%  theory- 
building 

RESEARCH  PROCESS 

Well-defined 
timeline  that 
incorporates 
formal  research 
course  work 

Same  as  DE 

Same  as  DE  and 

EN 

MANAGEMENT 

Very  few  recent 
continuing 
studies;  no 
formal  tracking 
of  indicators 

Almost  all  are 
continuing  or 
sponsored 
studies;  thesis 
database  used  to 
track  completion 
and  cost  avoid¬ 
ance  data 

Same  as  DE 

RESEARCH  PROGRAM 
IMPROVEMENT 

NEEDS 

Better  education 
of  advisors  on 
thesis  process; 
capability  to 
promote  earlier 
problem  identi¬ 
fication 

Lack  of  manpower 
is  biggest 
limitation; 
extended  tours 
for  military 
faculty 

Capability  to 
promote  continu¬ 
ing/sponsored 
studies  and 
earlier  problem 
identification 

RECOMMENDATIONS 
FOR  SYSTEM 

Sections  for 
topic  selection, 
ongoing  research 
review,  sponsor 
information,  and 
research  manage¬ 
ment  infoirmation 

Should  ensure 
alternatives  to 
building  a  new 
system  are 
examined 

Same  as  DE 
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SECTION  1 .  GENERAL 


1 • 1  Purpose  a£  Functional  Description .  This  Functional  Description 
for  the  prototype  AFIT  Research  Management  System  (ARMS)  is  written  to 
provide : 

A.  System  requirements  which  will  serve  as  a  basis  for  mutual 
understanding  between  the  future  users  and  the  developers 

B.  Information  on  performance  requirements,  improvements, 
impacts,  and  system  development  processes 

C.  A  basis  for  system  test  and  evaluation 
1,2  Project  References 

A.  Draft  Thesis  Proposal:  "Development  of  a  Prototype  Information 
System  for  Implementing  a  Research  Products  Reuse  Program, " 

6  Dec  91,  by  Captains  David  Schaaf  and  Carl  Scott 

B.  DoD  STD-7935,  "Automated  Data  Systems  Documentation,"  1  Nov  82 
1 v3  Terms  and  Abbreviations 

A.  ARMS  -  AFIT  Research  Management  System 

B.  Automated  Requirements  -  System  requirements  which  can  be 
implemented  in  the  ARMS  software  suite 

C.  Component  -  A  definable  part  of  a  system 

D.  Continuing  Research  Stream  -  Research  which  builds  upon  the 
results  of  previous  studies 

E.  DE  -  School  of  Civil  Engineering  and  Services 

F.  EN  -  School  of  Engineering 

G.  Faculty-Centered  Research  -  research  initiated,  managed,  and 
perpetuated  by  a  faculty  member 

H.  LS  -  School  of  Systems  and  Logistics 

I.  Nonautomated  Requirements  -  System  requirements  which  cannot 
be  implemented  as  part  of  the  ARMS  software  suite  (for 
example,  policy  changes) 

J.  Prototype  -  A  working  model  of  a  computer  system  which  is  used 
for  testing  the  viability  of  a  solution  to  a  problem  area 

K.  Research  Product  -  component  of  the  research  process  generated 
and  used  as  part  of  a  research  project.  (For  example,  data 
collection  instruments,  data,  statistical  models,  computer 
programs,  and  computer  program  documentation) 

L.  Reuse  -  The  application  of  existing  solutions  to  the  problems 
of  systems  development 

M.  Software  -  Computer  programs,  procedures,  associated 
documentation,  and  data  pertaining  to  the  operation  of  a 
computer  system  and  peripherals 
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N.  Software  Component  -  An  element  of  software  (code  module, 
design  document,  etc.)  that  performs  a  definitive  function 

O.  Software  Reuse  -  The  use  of  previously  developed  and/or 
acquired  software  components  in  a  new  development  project 

P.  System  -  A  collection  of  components  organized  to  accomplish  a 
specific  function  or  set  of  functions 
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SECTION  2. 


SYSTEM  SUMMARY 


2^  B^gkgrgunq  ■  The  idea  for  this  system  was  derived  from  the 
experiences  of  two  students  in  the  School  of  Systems  and  Logistics  (LS) . 
The  difficulties  of  determining  what  research  topics  are  important  to 
the  Air  Force  and  DoD,  as  well  as  the  complexity  of  scoping  a  workable 
research  project,  led  them  to  initiate  a  research  project  that  would  aid 
future  students . 

This  project  is  based  on  an  emerging  computer  science  technique 
called  software  reuse.  This  technique  is  commonly  defined  as  the  use  of 
previously  acquired  and  developed  concepts  and  objects  in  a  new 
situation.  In  the  area  of  software  development,  this  would  include 
items  such  as  source  code  modules,  program  architectures,  software 
documentation,  and  a  number  of  other  products.  The  intuitive  benefits 
of  this  technique  are  in  the  areas  of  productivity  (cost  and  time 
avoidance) ,  quality,  and  reliability.  To  be  effectively  implemented, 
reuse  requires  an  extensive  effort  to  determine  what  and  how  products 
should  be  cataloged  into  a  library  system.  The  library  system  then 
allows  the  products  to  be  located,  reviewed  for  applicability  to  a  new 
project,  and  subsequently  reused. 

Current  efforts  in  the  area  of  reuse  are  focused  on  applying  tlie 
technique  to  specific  "domains."  This  project  supports  the  intention  of 
these  efforts  by  adapting  and  evaluating  reuse  in  the  research  domain. 
Using  the  original  goal  of  building  a  research  products  reuse  system, 
the  student  researchers  found  that  there  are  many  management  benefits  to 
be  gained  by  employing  such  a  system.  This  insight  led  them  to  expand 
the  scope  of  the  system's  goals  to  those  listed  in  the  next  paragraph. 

2 . 2  Goals .  The  major  goals  of  the  prototype  ARMS  are  to; 

A.  Enhance  the  student  researcher's  capabilities  to  select  and 
scope  a  research  problem  which  is  vital  to  the  Air  Force  and 
DoD. 

B.  Improve  student  researcher's  productivity  by  adapting  and 
evaluating  the  concept  of  reuse  to  the  research  domain. 

C.  Increase  management  efficiency  by  providing  a  collection  of 
data  which  can  be  used  to  efficiently  meet  reporting  needs. 

D.  Stimulate  an  increased  conduct  of  continuing  research  streams 
within  LS  and  DE. 

2 . 3  Existing  Methods  and  Procedures .  Similar  academic  research 
processes  are  conducted  by  two  of  the  three  schools  at  AFIT .  Currently, 
the  Schools  of  Systems  and  Logistics  (LS)  and  Civil  Engineering  and 
Services  (DE)  allow  students  to  select  their  own  research  topics;  while 
the  School  of  Engineering  (EN)  employs  an  approach  that  fosters 
continuing  research  streams.  Aside  from  this  difference,  the 
description  of  the  existing  methods  and  procedures  provided  below 
applies  to  all  three  schools. 

It  is  important  to  note  that  modeling  the  entire  academic  research 
doir^ain  for  the  initial  prototype  ARMS  would  be  an  insurmountable  task 
during  the  short  research  period  afforded  AFIT  graduate  students . 
Therefore,  only  three  major  facets  of  the  domain  will  be  examined  during 
this  project:  research  topic  selection,  research  product  reuse,  and 
research  management . 
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2.3.1  Topic  Selection .  AFIT  graduate  students  researching  possible 
thesis  topics  can  refer  to  several  resources.  Many  of  these  resources 
are  found  in  the  academic  library,  which  contains  a  wide  variety  of 
services  for  conducting  topical  literature  searches.  Also,  research 
directors  and  some  faculty  members  formally  and  informally  "advertise" 
potential  topics.  However,  it  is  not  always  clear  to  the  student 
researcher  which  topics  are  of  vital  interest  to  the  Air  Force  and  DoD . 

The  availability  of  thesis  advisors  during  the  critical  initiation 
phase  of  new  students '  research  activities  is  another  area  that  impacts 
topic  selection.  At  present,  students  in  the  initial  period  of 
selecting  and  scoping  a  suitable  problem  for  research,  con^ete  for 
thesis  advisors  with  students  who  are  in  the  final  stages  of  their 
projects.  This  situation  not  only  impairs  the  progress  of  new 
researchers,  but  places  an  immense  burden  on  the  faculty.  Hence,  thesis 
advisors  are  not  readily  available  for  consultation  until  after  Labor 
Day.  By  that  time,  students  within  the  LS  school  (an"  in  some  cases  DE) 
are  nearing  completion  of  a  literature  review  assignment  for  the 
mandatory  COMM  687  (Theory  and  Practice  of  Professional  Communications ) 
course.  Under  the  current  system,  the  potential  benefits  of  COMM  687 
are  not  fully  realized.  Students  without  a  well-defined  topic  may  spend 
valuable  time  researching  a  subject  unrelated  to  their  thesis. 

2.3.2  Research  Product  Reuse .  During  the  process  of  completing  their 
theses,  student  researchers  generate  a  number  of  products  to  collect  and 
analyze  data.  In  addition,  some  student  researchers  develop  software 
systems  or  other  end  products  as  a  result  of  their  efforts.  The 
documentation  of  such  items  is  embodied  within  theses  and  often  archived 
without  consideration  for  further  use.  (As  noted  above,  the  EN  school 
has  a  program  of  continuing  research  streams  that  reuses  products  from 
past  studies.  However,  such  items  are  not  cataloged  or  made  available  to 
students  in  other  schools.)  Therefore,  research  products  reuse  is 
inhibited  in  part  by  the  difficulty  that  students  face  in  locating  the 
items  which  may  benefit  their  research  efforts.  Once  a  suitable  product 
for  reuse  is  located,  the  researcher  normally  must  recreate  it  using 
manual  methods . 

Based  on  the  concept  of  reuse,  student  researchers  potentially 
have  a  great  deal  to  gain  by  locating,  reviewing,  and  reusing  (.in  part 
or  as  a  whole)  quality  research  products  that  are  presently 
underutilized.  The  current  methods  of  locating  and  manually  reviewing 
theses  might  be  more  acceptable  if  students  had  a  greater  length  of  time 
to  conduct  their  research.  However,  the  current  12-15  month  start -to - 
finish  thesis  process  puts  pressure  on  students  to  complete  their 
research  projects  expediently.  Improvements  in  locating  and  reviewing 
products  could  potentially  relieve  pressure  by  making  validated  products 
readily  available  for  reuse. 

2.3.3  Research  Management .  The  process  of  managing  academic  research 
is  accomplished  at  AFIT  by  the  research  directors  for  each  school .  As 
focal  points  for  summarizing  and  formally  reporting  their  school's 
research  efforts,  the  directors  use  a  number  of  automated  and  non- 
automated  procedures.  However,  none  of  these  procedures  has  a  single 
collection  point  for  data.  Such  a  data  base  would  offer  many  potential 
benefits . 

Faculty  members  at  each  school  who  serve  as  thesis  advisors  share 
responsibility  in  the  area  of  research  management.  In  particular,  the 
underlying  basis  for  a  quality  program  of  continuing  research  streams  is 
faculty -centered  research.  However,  due  to  the  short  tenure  of  many 
military  faculty  members,  the  promotion  and  longevity  of  continuing 
research  streams  is  somewhat  restricted.  The  capability  to  track  on- 
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going  or  review  past  continuing  research  streams  could  produce  an 
improved  environment  for  similar  efforts  in  the  future. 

2 . 4  Proposed  Methods  and  Procedures .  This  section  outlines  the 
improvements  offered  by  the  proposed  ARMS  and  describes  the  system's 
impact  on  the  present  research  process  at  AFIT. 

2.4.1  Summary  Improvements .  Student  researchers,  faculty  members, 
and  research  directors  will  be  provided  with  certain  improvements  due  to 
the  implementation  of  the  ARMS.  The  improvements  are  grouped  into  four 
categories:  general,  research  topic  selection,  research  product  reuse, 
and  research  management . 

2 . 4 ■ 1 ■ 1  General  Improvements .  The  automated  portion  of  the  proposed 
ARMS  will  use  a  data  base  management  system  to  store  and  process  the 
data  needed  to  meet  student  researcher,  faculty,  and  management 
requirements.  As  an  automated  and  integrated  source  of  data,  the  ARMS 
will  offer  an  information  sharing  capability  among  the  three  AFIT 
schools.  Additionally,  the  ARMS  will  provide  intangible  benefits  of 
using  a  data  base  management  system  such  as  automated  record-keeping, 
improved  trend  tracking,  standardized/tailored  reporting,  and  other 
capabilities . 

2 . 4 . 1 . 2  Research  Topic  Selection  Improvements  .  The  ARI-IS  will  pro'v^ide 
an  expedient  method  for  reviewing  abstracts  which  describe  past  and  on¬ 
going  AFIT  research  projects.  The  system's  implementation  will 
potentially  alleviate  some  of  the  constraints  described  above  in  section 
2.3.1.  The  instinctive  advantages  of  using  an  automated  system, 
combined  with  the  resources  available  in  the  current  system,  will  help 
researchers ; 

A.  Begin  the  process  of  selecting/formulating  a  researchable 
topic  earlier  in  the  academic  year. 

B.  Review  a  broader  range  of  research  topics  more  expediently  and 
efficiently . 

C.  Scope  their  selected  research  problem  better. 

D.  Select  topics  that  lend  themselves  to  longitudinal  studies. 

E.  Investigate  the  application  of  research  designs  and 
methodologies  to  specific  types  of  studies. 

F.  Perform  studies  that  are  more  relevant  to  the  Air  Force  and 
DoD. 

In  addition  to  reviewing  past  and  on-going  AFIT  research  efforts, 
students  will  also  be  able  to  scan  new  topic  suggestions  using  the  ARMS. 

2 .4 . 1. 3  Research  Product  Reuse  Improvements .  The  ARMS  will  provide  an 
efficient  means  of  cataloging  research  products  into  a  "library  system" 
for  future  reuse.  The  resultant  library  system  will  allow  researchers 
to  expediently  locate,  review,  and  reuse  research  products  from  previous 
theses . 

2 . 4 . 1 . 3 . 1  Locating  Products .  The  ARMS  will  allow  researchers  to  locate 
reusable  research  products  in  many  different  ways.  The  following  is  a 
list  of  key  search  methods  that  may  be  used  individually  or  in  a  number 
of  combinations: 
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A.  Component  Type. 

1.  Thesis  documents 

2.  Data  collection  instruments  such  as  surveys,  interview 
formats,  and  questionnaires 

3.  Data  from  previous  collection  efforts 

4 .  Statistical  models  developed  to  analyze  collected  data 

5.  Computer  programs  such  as  decision  support  systems,  expert 
systems,  and  other  application  systems 

6.  Computer  program  documentation  such  as  functional 
descriptions,  design  documents,  source  code,  test  plans, 
and  user's  guides 

B.  Research  Category  such  as  Acquisition  Management,  Contract 
Management,  Software  Engineering,  and  Environmental  Management 

C .  School/Department 

D.  Author  Name 

E.  Subject/Keyword (s) 

The  capability  to  locate  specific  products  for  reuse  will  be  a 
major  improvement  over  the  systems  that  are  now  available  to  AFIT 
researchers.  Currently,  most  of  the  systems  only  provide  students  with 
the  capability  to  locate  thesis  documents  and  manually  review  them  for 
available  research  products . 

2 . 4 . 1 . 3 . 2  Reviewing  Products .  After  the  ARMS  locates  reusable  products 
based  on  the  provided  criteria,  the  researcher  will  be  able  to  review  an 
abstract  for  each  candidate  product.  Each  abstract  will  provide  both  a 
description  and  a  reuse  history  of  the  respective  product.  Researchers 
will  also  be  able  to  further  review  a  copy  of  the  product  to  determine 
if  it  is  reusable  in  their  research  project.  Overall,  the  capacity  to 
review  abstracts  and  copies  of  research  products  immediately  after 
locating  them  will  save  researchers '  time . 

2 . 4 . 1 . 3 ■ 3  Reusing  Products .  The  current  method  of  reusing  research 
products  normally  requires  the  researcher  to  recreate  the  products 
manually.  For  example,  researchers  must  either  retype  the  product  or 
become  proficient  at  using  an  electronic  scanner  with  optical  character 
reading  capability.  To  minimize  this  limitation,  the  ARMS  will  provide 
the  researcher  with  an  option  to  obtain  an  electronic  media  copy  of  the 
product.  The  ability  to  obtain  a  printed  copy  of  the  products  and 
respective  abstracts  will  also  be  available .  Combined  with  the  improved 
locating  and  reviewing  functions,  these  features  should  further  enhance 
the  productivity  of  student  researchers . 

2 . 4 . 1 . 4  Research  Management  Improvements .  The  ARMS,  by  virtue  of  the 
detailed  information  it  is  to  contain,  will  strongly  support  many 
management  applications.  The  following  is  a  representative  list  of 
functions  that  can  be  automated  by  employing  this  system: 

A.  Thesis  status  tracking  data  such  as  initiation  date,  personnel 
involved,  topic,  and  completion  date. 

B.  Thesis  publication  data  to  periodicals,  DTIC,  and  other 
archives . 

C.  Research  sponsorship  data  to  include  agency,  point  of  contact, 
funding  amounts,  and  cost -avoidance  estimates. 
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D.  Continuing  research  streamvs)  monitoring. 

E.  New  research  topic  screening/advertisement. 

In  designing  the  ARMS,  the  developers  will  review  the  structure  of 
existing  data  base  systems  used  by  research  management  personnel  to  the 
extent  that  information  is  provided  by  the  organizations  administering 
such  systems.  The  aim  of  this  approach  is  to  allow  for  the  transfer  of 
existing  data  into  the  ARMS. 

2.4.2  Summary  of.  Impacts .  The  ARMS  will  provide  more  timely  and 
accurate  information  to  support  the  conduct  and  management  of  the  AFIT 
student  research  process.  The  following  paragraphs  discuss  some  of  the 
system's  major  impacts  in  existing  organizational  and  operational 
environments.  In  particular,  the  following  paragraphs  outline  some  of 
the  major  nonautomated  requirements  that  must  be  addressed  before  the 
ARMS  can  be  fully  implemented. 

2  ,.4^2  - 1  Organizational  Impacts  . 

A.  A  number  of  personnel  (quantity  to  be  determined)  will  be 
required  to  perform  data  entry  operations.  This  effort  could 
be  minimized  depending  on  how  the  policies  and  procedures  for 
sustaining  the  system  are  structured.  See  paragraph 

2.4 .2 .2 .A. 

B.  A  database/system  manager  should  be  appointed  within  each  of 
the  three  schools  to  answer  user  questions  and  manage  school - 
specific  implementation  details. 

C.  An  application  administrator  should  be  assigned  within  AFIT/SC 
to  maintain  the  ARMS  application. 

2. 4. 2. 2  Operational  Impacts .  Several  policies  will  need  to  be 
developed  to  ensure  the  system  is  implemented,  operated,  and  maintained 
efficiently.  Specifically,  all  operational  areas  (student  researchers, 
faculty  members  (thesis  advisors),  and  researcher  directors)  impacted  by 
the  ARMS  should  have  defined  responsibilities.  The  following 
suggestions  should  be  considered  before  fully  implementing  the  system: 

A.  Require  student  researchers  to  submit  electronic  media  copies 
(diskette  or  other  suitable  means)  of  research  products  and 
abstracts  along  with  completed  theses.  This  requirement  would 
impose  a  minimal  workload  on  students,  while  significantly 
decreasing  the  data  entry  burden  for  the  system. 

B.  Assign  faculty  members  (thesis  advisors)  the  responsibilities 
of : 

1.  Evaluating  research  products  generated  during  student 
projects  for  inclusion  in  the  research  products  reuse 
subsystem.  This  decision  is  similar  to  the  one  that  is 
now  made  concerning  thesis  publication  and  distribution. 

2 .  Reviewing  research  topics  and  generating  new  ones  for 
input  to  the  topic  selection  part  of  the  ARMS. 

C.  Task  the  research  management  staff  (each  school's  research 
director  and  their  personnel)  with  overall  ownership 
responsibilities  for  the  system.  Such  responsibilities  might 
include:  monitoring  the  system's  data  accuracy  and  validity; 
acting  as  the  liaison  between  users  and  the  application 
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administrator  (AFIT/SC)  for  problem  resolution  and/or  system 
improvements;  and  managing  the  access  permissions  for  certain 
data  within  the  system. 

2  ■  4 ■ 2  ■  3  Developmental  Impacts .  Besides  designing  and  implementing  the 
data  structures,  control  programs,  and  initial  data  set  for  the 
prototype  ARMS,  the  developers  will  accomplish  the  following  tasks  as 
part  of  this  project: 

A-  Training  ('hands-on  instruction')  will  be  conducted  for  all 
personnel  participating  in  the  operational  test  of  the 
prototype  ARMS . 

B.  User  guides/instruction  sheets  will  be  developed  for  the 
various  ARMS  applications  (subsystems) . 

C.  Program  maintenance  documentation  will  be  developed  to  ensure 
the  system  can  be  enhanced  in  the  future. 

2 . 5  Assumptions  and  Constraints .  The  following  key  assumptions  and 
constraints  apply  to  this  project: 

A.  The  ARMS  is  a  prototype  development  that  will  potentially 
undergo  iterative  refinement  in  future  research  efforts  or  be 
turned  over  to  AFIT/SCV  for  maintenance.  Therefore,  coding 
and  documentation  conventions  consistent  with  those  used  in 
other  AFIT  automation  systems  will  be  employed. 

B.  The  project  is  limited  to  the  use  of  existing  AFIT  computing 
hardware  and  software. 

C.  The  prototype  system  will  be  developed  to  handle  the  storing 
and  processing  of  unclassified  information  only. 
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SECTION  3.0  DETAILED  CHARACTERISTICS 


3 . 1  General  Performance  Requirements .  The  list  below  provides  general 
performance  requirements  that  the  automated  portion  of  ARMS  must  meet 
while  providing  the  improvements  and  functions  described  in  sections  2.4 
and  3.2. 

A.  Provide  formatted  displays  for  interactive  (on-line)  data 
entry . 

B.  Minimize  user  entries  by  providing  default  values  and  range 
boundaries  where  possible. 

C.  Provide  feedback  when  a  transaction  has  either  been  completed 
or  rejected. 

D.  Ensure  that  only  completed  transactions  are  stored  in  the 
database . 

E.  Provide  an  ad  hoc  query  and  reporting  capability  to  users  with 
special  needs  and  advanced  training. 

F.  Permit  the  generation  of  predefined  reports. 

G.  Permit  retrieval  of  data  by  the  user  from/to  terminals  or  to 
printers . 

H.  Provide  each  user  the  authority  to  access  records  and  data  in 
their  areas  of  responsibility. 

I.  Limit  each  user  to  specified  processing  functions  based  on 
assigned  responsibilities. 

J.  Provide  daily,  weekly,  and  monthly  database  backup  capability. 


(NOTE:  A  detailed  description  of  the  following  four  sections  will  be 

developed  during  the  design  process .  Any  initial  information  available 
is  provided  in  each  paragraph.  ) 

3 . 2  Functional  Area  System  Functions .  Based  on  the  improvements  listed 
in  section  2.4,  the  automated  portion  of  ARMS  will  have  at  least  three 
major  subsystems --the  topic  selection  subsystem,  the  research  products 
reuse  subsystem,  and  the  management  subsystem.  Additional  subsystems 
will  likely  be  required  to  permit  database  maintenance  activities . 

3 . 3  Inputs-Outputs .  The  data  elements  to  be  included  in  the 
construction  of  the  ARMS  will  be  defined  and  documented  as  required  by 
the  DoD-STD-7935  during  the  design  process.  The  input  of  data  will 
primarily  be  accomplished  through  the  keyboard  of  a  personal  computer  or 
other  virtual  display  terminal  connected  to  the  AFITNET.  The  ARMS  will 
also  provide  an  interface  for  transferring  data  from  selected  disk 
drives  of  connected  computers  and  terminals .  Outputs  from  the  system 
will  include  screen  displays,  printouts,  disk  files,  or  tape  files. 

3 . 4  Data  Base  Characteristics .  As  stated  above,  the  data  elements  for 
the  system  will  be  defined  and  documented  as  required  by  DoD-STD-7935 . 
Based  on  the  requirement  to  use  an  already  available  relational  database 
management  system,  all  data  elements  will  be  represented  within  a  set  of 
tables.  Casual  users  of  the  system  will  not  need  to  know  the  details  of 
how  the  data  is  stored  and  will  be  shielded  from  such  information  by  a 
series  of  menu-  and  prompt-driven  interfaces. 
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3 , 5  Failure  Contingencies . 


3.5.1  Types  of  Failures .  Database  failures  for  the  ARMS  can  fall  into 
three  categories : 

A.  Transaction  Failure:  A  failure  of  a  single  transaction  of  the 
database,  usually  caused  by  a  data  error. 

B.  Software  Failure:  A  failure  of  the  database  management  system 
itself,  usually  caused  by  a  programming  error. 

C.  Hardware  Failure:  A  failure  of  the  system  hardware,  either 
recoverable  or  catastrophic.  Recoverable  errors  are  typically 
power  outages  and  catastrophic  errors  usually  destroy  data  in 
the  database  requiring  a  complete  recovery  of  the  database 
from  a  backup  copy. 

3.5.2  Methods  to  Recover  From  Failures .  To  be  determined  based  on  the 
hardware  and  software  systems  selected  to  implement  the  system. 

3 . 6  Security .  The  initial  prototype  ARMS  will  be  developed  to  store 
and  handle  only  unclassified  data.  Additional  precautions  for  handling 
additional  types  of  data  may  be  required  during  future  enhancement 
ef  forts . 
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SECTION  4.  DESIGN  DETAILS 


The  design  details  for  the  prototype  ARMS  will  not  be  determined 
until  the  requirements  listed  in  Sections  2  and  3  have  been  validated. 
In  addition,  the  activities  of  this  project's  third  objective  (as 
outlined  in  paragraph  7.2.3)  must  be  completed.  This  section  will  be 
written  as  part  the  project's  fourth  objective. 


SECTION  5 .  ENVIRONMENT 

The  computer  resources  environment  for  the  ARMS  will  be  determined 
during  the  completion  of  the  third  objective  of  this  research  project 
(see  paragraph  7.2.3.)  This  section  will  be  written  at  that  time. 


SECTION  6.  COST  FACTORS 

Cost  factors  are  not  addressed  in  this  functional  description 
because  the  initial  version  of  the  ARMS  is  being  developed  as  a 
prototype  under  the  auspices  of  a  graduate  student  research  project. 
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SECTION  7.  SYSTEM  DEVELOPMENT  PLAN 


7 ■ 1  Overall  Approach .  The  development  of  the  prototype  ARMS  will  be 
accomplished  using  the  seven  research  objectives  described  in  the  draft 
thesis  proposal  referenced  in  paragraph  1.2. A. 

7 . 2  System  Development . 

7.2.1  Objective  H  -  Describe /Define  the  Current  AFIT  Research 
Environment .  A  detailed  description  of  the  current  AFIT  research 
environment  is  needed  to  clearly  understand  the  objectives,  alternatives 
and  constraints  of  the  research  problem.  The  following  steps  will  be 
taken  to  accomplish  this  objective: 

A.  Interview  Research  Directors  for  the  AFIT  Schools  of 
Engineering  (EN) ,  Systems  and  Logistics  (LS) ,  and  Civil 
Engineering  (DE)  to; 

1)  To  gain  an  understanding  of  the  general  structure, 
management  philosophy,  and  overall  strengths  and 
weaknesses  of  each  school's  research  program. 

2)  To  present  the  basic  tenets  of  this  research  proposal  and 
obtain  general  feedback  on  the  overall  project . 

3)  To  solicit  recommendations  about  desired  requirements  for 
the  prototype  ARMS . 

B.  Investigate  and  document  the  major  resources  available  for 
conducting  research. 

7. 2, ,.2  Qb.i£Ctiy.e  12  -  Psfine  and  Validate  tke  Requirements  the  AFIT 
Research  Management  System  XAEMSl-  The  primary  goal  of  this  research 
objective  is  to  produce  a  validated  requirements  document  for  the  ARMS. 
Since  the  system  may  require  the  implementation  of  many  nonautomated 
requirements,  the  document  developed  below  must  not  be  constrained  to 
only  those  tasks  that  can  be  automated.  This  fact  will  be  emphasized 
throughout  the  process  of  completing  the  following  steps : 

A.  Develop  a  Proposed  Set  of  Requirements.  A  proposed  set  of 
requirements  will  be  developed  based  on  the  interviews 
conducted  in  objective  one  and  the  insights  of  the  students 
developing  the  system. 

B.  Design  and  Distribute  a  Functional  Description  (FD)  of  the 
System  to  Validate  Proposed  Requirements.  The  FD  (which  is 
this  document)  will  allow  future  users  of  the  system  to 
influence  the  development  of  the  prototype. 

C.  Analyze  Validation  Results  and  Update  the  FD .  The  results  of 
the  validation  effort  conducted  in  the  above  step  will  be 
analyzed  and  used  to  update  the  system's  FD.  The  analysis 
accomplished  during  this  step  will  focus  on  determining  if  the 
proposed  changes  or  additions  are  consistent  with  the  purposes 
of  this  system. 

J-.2....3  Qb.3e.g..tiyg  11  '  Determine  the  Specific  Requirements  for 
Automation  and  Select  the  Prototype ' s  Target  Architecture .  There  are 
two  primary  sets  of  decisions  that  must  be  made  to  complete  this 
objective.  The  first  involves  a  determination  of  which  requirements  can 
be  automated  as  part  of  the  initial  prototype  system.  The  second  set  of 
decisions  will  involve  an  assessment  of  which  computing  hardware  and 


C-14 


software  can  be  used  to  support  the  development  and  initial  test  of  the 
prototype  system.  The  final  decisions  in  both  of  these  areas  will  be 
affected  by  time  and  resource  constraints  that  cannot  be  fully  estimated 
at  this  juncture.  The  following  steps  will  be  accomplished  to  meet  this 
objective : 

A.  Select  Requirements  for  Automation.  The  first  step  in  this 
process  will  be  to  defer  all  of  the  nonautomated  requirements 
needed  to  fully  implement  the  ARMS.  The  second  and  final  step 
will  require  the  developers  to  determine  (based  on  time  and 
resource  restrictions)  which  automation  requirements  to 
include  in  the  initial  design  of  the  prototype.  The  goal  of 
this  step  is  to  ensure  that  the  requirements  selected  will 
demonstrate  the  potential  usefulness  of  the  system.  Those 
requirements  not  selected  for  automation  in  this  step  will 
form  the  foundation  of  the  recommended  path  for  follow-on 
research . 

B.  Examine  AFIT  Computing  Resources  and  Select  Target 
Architecture.  The  selection  of  a  host  computer  system  and 
development  tools  is  required  before  the  prototype  can  be 
designed.  An  evaluation  of  available  AFIT  computing  resources 
will  be  conducted  concurrently  with  the  above  research 
objectives . 

7.2.4  Objective  M  -  Develop  the  Prototype  System.  The  prototype  will 
be  developed  based  on  the  results  of  the  above  research  objectives . 
Detailed  documentation  on  the  design  and  operation  of  the  system  will  be 
needed  to  ensure  the  initial  prototype  can  be  efficiently  operated 
during  the  operational  test,  and  subsequently  improved  during  follow-on 
research  efforts.  These  requirements,  as  well  as  the  formal  coding  of 
the  information  system's  data  structures  and  control  programs,  will  be 
fulfilled  by  completing  the  following  steps: 

A.  Design  and  Program  the  Prototype  System.  The  system  will  be 
designed  using  established  software  engineering  principles. 

In  particular,  the  system's  design  will  be  completed  using  a 
combination  of  data  flow  diagrams  and  program  control 
structure  charts  before  any  computer  programming  is  started. 

In  addition,  a  set  of  revision  control  procedures  will  be 
established  and  followed  throughout  the  programming  process  to 
ensure  the  system's  development  is  properly  managed. 

B.  Write  Operating  and  System  Administration  J.istructions .  .A  set 
of  initial  operating  instructions  will  be  developed  to  help 
personnel  use  the  system  during  the  operational  test.  A  set 
of  instructions  will  also  be  developed  on  how  to  perform 
system  administration  functions  (if  deemed  necessary) .  The 
documents  developed  to  complete  this  step  will  be  evaluated 
during  the  operational  test  of  the  system. 

7 -■  2 . 5  Qj?jectiy.g  M  -  Operationally  Ies.t  thg  Prbtgtypg  System.  The 
steps  performed  to  meet  this  objective  involve  populating  the 
information  system  with  initial  data,  establishing  evaluation  tools,  and 
conducting  an  operational  test  of  the  system.  The  final  step  of  this 
objective  will  require  the  cooperation  of  several  departments  within  the 
three  AFIT  schools. 

A.  Populate  Prototype  System.  During  this  step,  the  system  will 
be  populated  with  an  initial  set  of  data.  The  current  plan  is 
to  have  a  minimum  of  fifty  research  products  in  the  database 
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for  the  operational  test.  These  products  will  be  derived  from 
recent  award  winning  theses . 

B.  Selection/Development  of  Evaluation  Tools.  Prior  to 
conducting  the  operational  test,  a  set  of  appropriate 
evaluation  tools  for  assessing  technical  adequacy  and 
operational  suitability  will  be  researched.  If  suitable  tools 
are  not  found,  they  will  be  developed. 

C.  Conduct  Operational  Test.  The  formal  operational  test  of  the 
system  will  be  conducted  using  faculty  members  and  students 
from  the  School  of  Systems  and  Logistics.  This  testing 
limitation  is  being  imposed  to  eliminate  difficulties  involved 
in  coordinating  a  large  formal  test.  A  limited,  informal  test 
of  the  system  may  be  commissioned  to  allow  the  research 
directors  at  the  other  two  schools  to  assess  the  value  of  the 
prototype . 

7-2.6  QbjgCtjvg  M  -  Analyze  Operational  Test  Results .  During  the 
completion  of  the  operational  test,  test  team  members  will  use  a  set  of 
predefined  tools  to  document  their  evaluation  of  the  system.  The  data 
gathered  during  the  test  will  be  used  to  perform  the  following  steps: 

A.  Assess  Technical  Adequacy.  To  assess  the  technical  adequacy 
of  the  system,  a  statistical  analysis  will  be  performed  on 
responses  to  questions  that  relate  to  the  basic  performance 
characteristics  of  the  system.  Specifically,  assigned 
subjective  ratings  will  be  evaluated  for  factors  such  as  ease 
of  use,  speed  of  data  retrieval,  clarity  of  data  presentation, 
as  well  as  a  number  of  other  man-machine  interface 
considerations . 

B.  Assess  Operational  Effectiveness/Suitability.  The  operational 
effectiveness  of  the  prototype  system  will  be  assessed  by 
performing  a  statistical  analysis  on  responses  to  questions 
that  pertain  to  the  ability  of  the  system  to  accomplish  its 
operational  mission.  The  assessment  of  operational 
suitability  will  involve  making  a  determination  on  whether  the 
prototype  system  should  continue  in  the  iterative  improvement 
process . 

7.2.7  Objective  12  -  Develop  Recommended  Path  for  Follow-on 
Development/  Research .  In  light  of  this  project’s  "proof  of  concept" 
nature,  the  proper  completion  of  this  objective  is  very  important. 
Therefore,  items  for  follow-on  research  will  be  gathered  and  documented 
during  the  conduct  of  objectives  one  through  six.  Following  this 
approach  will  reduce  the  completion  and  documentation  of  this  objective 
to  partitioning  the  issues  into  the  two  main  categories  listed  below. 

A.  Follow-on  Development  of  the  Prototype  System.  The  research 
items  in  this  category  will  focus  on  improving  the  prototype 
system.  Known  candidate  items  for  inclusion  in  this  category 
are : 

1)  Requirements  that  were  not  selected  for  automation  during 
objective  three. 

2)  Changes  and  additions  recommended  by  the  analysis  results 
in  objective  six. 

B.  Proposed  Corollary  Studies.  The  follow-on  research  in  this 
category  will  focus  on  the  need  for  corollary  studies  to 
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determine  how  the  non- automated  requirements  for  the  system 
can  be  implemented.  The  primary  items  for  this  category  will 
be  derived  during  research  objectives  two  and  three. 


C-17 


Appendix  Summary  2I  £D  Validation  Comments 


The  summary  below  lists  the  comments  provided  by  five  of  the  six 
respondents  to  the  FD  validation  effort.  The  EN  director's  comments  are 
specifically  addressed  in  Chapter  IV  and  are  not  revisited  in  this 
appendix.  A  brief  explanatory  note  that  includes  the  item's  final 
disposition  is  provided  for  each  comment. 


1.  You  may  want  to  consider  an  off-line  vice  on-line  archival  system 
for  electronic  copies  of  components.  (Reference  paragraph 
2. 4. 1.3. 3.) 

Disposition:  This  alternative  will  be  added  to  the  next  version 
of  the  FD. 


2.  It  sounds  like  new  manpower  may  be  needed  to  manage  the  system. 
Can  the  job  be  handled  by  people  already  in  place?  (Reference 
paragraph  2. 4. 2.1.) 

Disposition:  A  follow-on  study  needs  to  assess  this  question  and 
number  of  others  that  relate  directly  to  a  cost- 
benefit  analysis. 


3.  If  you  are  going  to  use  the  Oracle  relational  database  management 
system,  you  may  want  to  consider  improving  its  user- interface  by 
using  embedded  structured  query  language  commands  in  a  high  order 
language.  (Reference  paragraph  3.1.) 

Disposition:  For  expediency  purposes,  the  standard  Oracle 

development  environment  was  used  for  this  initial 
prototype.  Future  improvements  to  the  prototype  or 
a  contract  effort  to  build  a  production  system 
should  consider  this  point. 


4 .  You  may  want  to  consider  making  the  human-machine  interface 

resemble  that  of  another  commonly  used  system  (like  the  library 
ILS)  to  minimize  the  student  learning  curve  for  a  new  system. 
(Reference  paragraph  3.1.) 

Disposition:  An  attempt  will  be  made  to  standardize  the  user 

interface  with  other  existing  systems.  However,  it 
would  seem  infeasible  to  be  able  to  replicate  an 
interface  in  the  short  time  we  have  to  develop  the 
prototype,  given  the  fact  that  it  likely  required  a 
significant  expenditure  of  resources  by  the  commercial 
developers  to  develop  the  interfaces  for  the  existing 
products.  This  factor  should  be  examined  during 
successive  cycles  of  the  spiral  model. 


5.  AFIT/SCOS  has  previously  looked  at  electronic  archival  of  software, 
data,  etc.,  from  previous  research.  The  students  should  check  with 
them  to  see  what  has  been  done  in  this  area.  (Reference  paragraph 
2 . 4 . 1 . 3  and  its  subparagraphs . ) 
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Disposition:  This  item  was  discussed  with  the  personnel  in  the 

AFIT/SCOS  branch.  They  advised  that  no  formal  study 
had  been  done  on  this  issue  or  is  planned  at  this 
time . 


6 .  Some  of  the  information  planned  for  incorporation  into  the  new 
system  is  a  duplicate  of  what's  already  available  in  the  Defense 
Technical  Information  Center's  (DTIC)  Defense  RDT&E  Online  System 
(DROLS)  data  base.  However,  the  actual  computer  models,  programs, 
etc.,  which  are  a  part  of  the  thesis,  are  not  separately  indexed  in 
DROLS.  That  aspect  of  the  proposed  ARMS  would  be  a  definite 
improvement  over  DROLS.  (Reference  paragraph  2. 4. 1.3  and  its 
subparagraphs . ) 

Disposition:  Only  a  limited  amount  of  data  available  within  the 
existing  library  systems  will  be  duplicated.  For 
example,  the  thesis  designator,  title,  and  author 
information  will  be  duplicated  in  the  ARMS.  However, 
detailed  indicators  concerning  a  thesis  categorization 
as  a  continuing,  sponsored,  or  award-winning  study 
can  not  be  found  in  these  or  any  of  the  school - 
specific  automation  systems  that  track  theses 
completion.  There  are  a  number  of  other  examples  of 
this  fact  located  in  the  FD  and  the  thesis.  This 
issue  should  remain  an  area  for  future  consideration 
and  review. 


7.  Who  would  be  responsible  for  inputting  the  data  for  retrospective 
theses?  I  don't  see  any  organization  willing  taking  on  this  added 
responsibility  during  the  current  environment  of  manpower 
downsizing.  (Reference  paragraph  2. 4. 1.3  and  its  subparagraphs.) 

Disposition:  Similar  to  comment  #2  above,  a  cost-benefit  analysis 

should  be  conducted  to  determine  if  it  would  be  worth¬ 
while  to  input  past  theses.  This  task  is  not  within 
the  scope  of  the  current  study. 


8.  Will  the  system  include  doctoral  dissertations  done  here  at  .AFIT, 
and  those  done  at  civilian  schools  with  AFIT  sponsorship?  (General 
comment . ) 

Disposition:  This  requirement  will  be  added  to  the  next  version  of 
the  FD. 


9.  Section  2.4.1. 3.1  should  probably  include  the  names  of  advisors. 

Disposition:  This  requirement  will  be  added  to  the  next  version  of 
the  FD. 


10.  Section  2. 4. 2. 2. A  states  that  the  tasking  "would  impose  a  minimal 
workload  on  students."  This  is  probably  not  always  the  case  with 
very  long  theses  and  dissertations. 

Disposition:  This  appears  to  be  a  misconception.  This  item  will  be 
better  defined  in  the  next  version  of  the  FD . 
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Appendix  £j.  Prototype  ARMS  Evaluation  Questionnaire 


INSTRUCTIONS 

Please  rate  the  sliding-scale  questions  according  to  the  following 
legend : 

1  -  strongly  agree  4  -  disagree 

2  -  agree  5  -  strongly  disagree 

3  -  neutral  6  -  not  applicable  or  evaluated 

GENERAL  INFORMATION 

1.  I  consider  myself  knowledgeable  about  the  general  operation  of 
computers  and  database  management  systems . 

1 . 2 . 3 . 4 . 5 . N 

2.  The  menus'  help  screens  were  self-explanatory  and  provided  me  with 
enough  information  to  begin  using  the  system. 

1 . 2 . 3 . 4 . 5 . N 

SUBSYSTEM  EVALUATION 

3.  I  felt  confident  operating  this  subsystem  using  only  the  on-screen 
help  facilities  (field/option-specific  help  bar,  separate 
instruction  blocks,  etc) : 


Research  Topic  Selection: 

1.  .  . 

.  .  .  .2 . 

.  .  3  .  .  .  . 

.  .  .4  .  .  . 

.  .  .  .  5  .  .  . 

.  .  .  .  N 

Research  Products  Reuse: 

1.  .  .  , 

- 2 . 

.  .  3 _ 

.  .  .4  .  .  . 

,  .  .  .5.  . .  . 

.  .  .  .  N 

Research  Management : 

1.  .  .  , 

.  .  .  .2 . 

,  .  3  .  .  .  . 

.  .  .  4  .  .  . 

.  ...  5  ...  . 

.  .  .  .N 

I  found  this  subsystem  easy  to 

learn  and 

use  : 

Research  Topic  Selection: 

1 .  .  . 

.  .  .  .2 . 

.  .  3  .  .  .  . 

.  .  .  4  .  .  . 

.  .  . .5.  .  .  . 

.  .  .  N 

Research  Products  Reuse : 

1.  .  .  , 

.  .  . .2 . 

.  .  3  .  .  .  . 

.  .  .  4  .  .  .  , 

.  ...  5  ...  . 

.  .  .  .  N 

Research  Management : 

1.  .  .  , 

.  .  .  .2 . 

.  .  3  .  .  .  . 

.  .  .4  .  .  .  , 

.  ...  5  ...  . 

,  .  .  .N 

5.  I  feel  the  type  of  automated  information  provided  by  this  subsystem 
could  help  (or  could  have  helped)  me  more  efficiently  conduct  a 
research  study: 

Research  Topic  Selection:  1 . 2 . 3 . 4 . 5 . N 

Research  Products  Reuse  :  1 . 2 . 3 . 4 . 5 . N 

Research  Management :  1 . 2 . 3 . 4 . 5 . N 
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6.  I  would  use  (or  would  have  used)  this  subsystem  for  research  work  if 
it  were  fully  operational; 

Research  Topic  Selection:  1 . 2 . 3 . 4 . 5 . M 

Research  Products  Reuse;  1 . 2 . 3 . 4 . 5 . N 

Research  Management:  1 . 2 . 3 . 4 . 5 . M 

OVERALL  SYSTEM  EVALUATION 

7.  I  liked  the  following  features  about  the  subsystems  I  used  (circle 
all  that  apply) ; 

a.  screen  displays  (screen  organization). 

b.  functions  (what  the  subsystems  do). 

c.  processing  speed  (system  response  time). 

d.  data  (applicability,  breadth) . 

e.  written  instructions. 

f.  on-line  help  instructions. 

8 .  The  following  features  of  the  subsystems  I  used  need  to  be  improved 
(circle  all  that  apply); 

a.  screen  displays  (screen  organization). 

b.  functions  (what  the  subsystems  do). 

c.  processing  speed  (system  response  time) . 

d.  data  (applicability,  breadth) . 

e.  written  instructions. 

f.  on-line  help  instructions. 


9 .  I  used  the  AFIT  Research  Management  System: 

a.  less  than  15  minutes. 

b.  15  to  30  minutes. 

c.  30  minutes  to  one  hour. 

d.  more  than  one  hour. 


CONCLUSION 

If  you  have  other  comments,  please  record  them  below  or  attach  a 
separate  page.  Thank  you  for  your  participation. 


E-  2 


Appendix  Ej_  AEM2  User’s  Guide 


User's  Guide 
for  the 
Prototype 

AFIT  Research  Management  System  (ARMS) 
by 

Captain  Carl  W.  Scott 
Captain  David  Schaaf 

Current  as  of:  31  July  1992 


F-1 


TABLE  OF  CONTENTS 


Introduction 


■k 


Accessing  the  System  .  * 

Basic  Keyboard  Commands  .  * 

Help  System  .  * 


System  Operation  .  * 

Research  Topic  Selection  Subsystem  .  * 

Querying/Reviewing  a  Thesis  Record  .  * 

Querying/Reviewing  a  Topic  Record  .  * 

Research  Products  Reuse  Subsystem  .  * 

Querying/Reviewing  a  Component  Record  .  * 

Research  Management  Subsystem  .  * 

Querying/Reviewing  a  Sponsor  Record  .  * 

Querying/Reviewing  a  Thesis  Advisor  Record  .  * 

Database  Administration  Subsystem  .  * 

Exiting  the  System  .  * 

Final  Comments  .  * 


*  The  normal  page  numbering  for  this  document  was  eliminated  so  that  it 
could  be  incorporated  into  the  thesis. 


F-2 


INTRODUCTION 


The  prototype  AFIT  Research  Management  System  (ARMS)  is  a  multi¬ 
user  database  that  was  developed  as  part  of  a  graduate  thesis  project. 
The  system's  primary  functions  include  storing  and  providing  access  to 
information  which  can  aid  student  researchers  in  preparing  for  and 
conducting  their  thesis  work.  Specifically,  the  ARMS  contains 
subsystems  for  assisting  researchers  with  the  tasks  of  developing  a 
research  topic,  finding  a  thesis  advisor,  and  locating  a  reusable 
component  (such  as  a  survey,  questionnaire,  program,  or  other  applicable 
item)  that  could  be  used  or  modified  for  use  in  their  projects.  The 
ARMS  is  also  intended  to  provide  faculty  and  research  management 
personnel  with  timely,  accurate  information  about  the  school's  research 
program. 

The  prototype  system  described  in  this  guide  was  developed  using 
the  ORACLE  database  management  system  and  associated  tools.  The  man- 
machine  interface  is  primarily  menu-driven  and  requires  the  user  to  type 
in  specific  criteria  on  which  to  conduct  queries.  No  knowledge  of 
structured  query  language  (SQL)  is  required  by  students  or  faculty  to 
operate  the  ARMS.  However,  careful  attention  should  be  paid  to  the 
keyboard  differences  between  the  various  types  of  computers  available 
for  use  at  AFIT.  Specific  examples  detailing  how  to  operate  the  system 
are  provided  later  in  this  guide. 

The  goal  of  building  this  initial  version  of  the  prototype  ARMS 
was  to  provide  a  method  of  evaluating  the  benefits  and  practicality  of : 
(1)  adapting  the  "reuse"  philosophy  to  research,  and  (2)  improving  the 
research  conduct  and  management  processes  through  specialized 
automation.  The  present  system  is  mature  only  to  the  extent  that  it 
demonstrates  the  conceptual  gains  which  could  be  provided  by  a  full 
production  system. 


ACCESSING  THE  SYSTEM 

The  prototype  ARMS  is  currently  hosted  on  the  VAX  Cluster  and  must 
be  accessed  through  the  AFITNET .  For  the  purpose  of  the  operational 
test,  most  personnel  will  only  be  able  to  view  data.  Privileges  to  add, 
delete,  or  change  information  in  the  system  are  reserved  for  the 
personnel  developing  the  ARMS . 

The  following  steps  should  be  taken  to  access  the  ARMS: 

1.  Log  into  the  LS_LAN  NOVELL  menu  system  and  select  the 
following  options  in  succession  'A  -  Applications',  'F  - 
Mainframe  Connections’,  and  'A  -  Connect  to  the  Mainframe 
Computers ' . 

2 .  Type  LANCER  and  press  RETURN  when  prompted  for  ' what  system  to 
connect  to . ' 

3 .  Respond  with  your  personal  account  information  when  presented 
with  the  VAX  login  prompts  for  'Username:'  and  'Password.'. 

4.  Once  you  receive  the  VAX  prompt,  type  CD  GSS92D; [CSCOTT . ARMS] 
and  press  RETURN . 

5.  Type  SQLMENU  ARMS  ARMSJUSER/??????  (where  the  question  marks 
represent  the  unique  password  which  will  be  provided  to  you 
during  the  evaluation)  and  press  RETURN. 
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You  should  now  be  at  the  ARMS  main  menu  (Figure  4)  where  you  can 
begin  conducting  queries  based  on  the  access  privileges  provided  to  you 
by  the  system  administrators . 


BASIC  KEYBOARD  COMMANDS 

The  prototype  ARMS  has  several  preset  keyboard  ' keys '  which  must 
be  used  to  properly  operate  the  system.  Most  of  these  keys  can  be  found 
on  the  'function  key'  row  and  'numeric  keypad'  of  your  keyboard.  Useful 
results  of  these  keys  and  messages  are  provided  on  the  'help  bar' 
located  at  the  bottom  of  the  screen.  The  most  important  keys  and  their 
meanings  are  summarized  below. 

FUNCTION  KEY  1  (FI)  -  is  the  'execute  query'  key  which  should  be 
pressed  after  you  have  entered  a  search  string  to  start  a 
search.  If  the  search  is  successful,  the  first  record 
retrieved  will  be  displayed. 

FUNCTION  KEY  3  (F3)  -  is  the  'commit'  key  which  is  used  to  update 
a  record.  This  key  will  be  disabled  for  most  operational 
test  users . 

FUNCTION  KEY  4  ( F4 )  -  is  the  'cancel/exit'  key.  Pressing  this  key 
will  return  you  to  the  previous  menu. 

KEYPAD  <0>  (KPO)  -  is  the  'help'  key.  This  key  is  active  while 
any  'menu',  'query',  and  'information'  screen  is  displayed 
and  provides  applicable  help  information  to  that  screen. 

KEYPAD  <1>  (KPl)  -  is  the  'next  block'  or  'next  page'  key.  It  is 
active  in  certain  multi-block  or  multi-page  forms  to  provide 
access  to  different  display  screens  or  parts  thereof. 

KEYPAD  <2>  (KP2)  -  is  the  'previous  block'  or  'previous  page’  key. 

KEYPAD  <3>  (KP3)  -  is  the  'display  component'  key.  It  is  active 
only  when  a  record  in  the  'Research  Products  Reuse 
Subsystem'  is  being  displayed.  If  an  electronic  copy  of  the 
reusable  component  is  available,  pressing  this  key  will 
display  it  in  text- file  format. 

KEYPAD  <4>  (KP4)  -  is  the  'get  next  record'  key  which  can  be  used 
after  you  have  executed  a  search  and  a  record  is  displayed. 
The  'help  bar'  will  notify  you  when  no  more  records  match 
the  search  criteria  you  provided.  Pressing  the  DOWN  ARROW 
accomplishes  this  same  function. 

KEYPAD  <5>  (KPS)  -  is  the  'get  previous  record'  key.  The  UP  ARROW 
accomplishes  the  same  function. 

KEYPAD  <6>  (KP6)  -  is  the  'display  abstract  text'  key.  It  is 
active  in  all  displays  when  an  abstract  is  provided  to 
further  describe  the  record  presented  on  the  screen.  A 
notice  will  appear  at  the  bottom  of  the  display  when  this 
key  is  available  for  use. 

There  are  a  number  of  other  keys  which  have  duplicate  functions  to 
those  just  described.  However,  the  above  keys  should  be  used  to  ensure 
proper  operation  of  the  system. 
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HELP  SYSTEM 


A  limited  help  system  is  provided  with  this  version  of  the  ARMS. 

As  indicated  in  the  above  section,  pressing  KPO  while  any  'menu', 

'query',  or  'information  record'  screen  is  displayed  will  present  an 
appropriate  help  screen.  (Note:  Help  is  not  active  during  the  'view 
abstract'  and  'view  component'  operations  because  a  VMS  operating  system 
command  is  used  to  perform  them.  )  Figures  1,  2,  and  3  illustrate  the 
screens  that  will  appear  when  KPO  is  pressed  with  a  menu,  query,  and 
information  screen  displayed,  respectively.  Additional  help  is  provided 
on  many  of  the  screens  in  the  form  of  'text  boxes'  or  one-line  messages 
that  appear  m  the  inverse  line  block  at  the  bottom  of  the  page. 


AFIT  Research  Hanagenent  Sgsten  (RRfIS) 

rtain  Menu 


Help  for  Research  Topic  Selection  Subsystem  Option 


This  option  provides  access  to  the  Research  Topic  Selection  Subsystem 
(RTSS)  menu.  The  goal  of  the  RTSS  is  to  provide  student  researchers 
uith  an  expedient  method  of  reviewing  information  available  on  past, 
ongoing,  and  sponsored  theses  as  well  as  neu  research  requests.  The 
revieu  of  this  information  is  intended  to  assist  student  researchers 
uith  the  task  of  selecting  and  scoping  a  thesis  topic. 


(lake  your  choice: 

Press  8  on  the  keypad  <KPO>  for  help — ensure  NUULOCK  is  on 


v  Sun  Jul  26  85:11:11  19S2  OSC  DBG 

End  of  help  info,  type  any  key  to  return  to  menu.. 


Replace  ftRUS  (flRHS  ) 


Figure  1.  Menu  Help  Screen  Example 


I  Press  <Ft>  to  return  to  main  form 


FUrtCTIOn  KEYS 


OTHER  KEYS 


ESC-U - >Display  Lookup  Table 


Char  node :  Rep  lace  Pape  1  Count :  •K) 

Figure  2.  Query  Help  Screen  Example 


FI 

Ft 

Execute 

Cancel/' 

Query 

Exit 

KEYPAD  <KP>  KEYS 


7 

B 

3 

Clear 

Field 

Redisplay 

Screen 

4 

5 

6 

;|j||UI 

Z 

3 

ENTER 

Previous 

Page 

< 

) 

Show 

Keys 
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Char  node:  Replace  Page  1 


Figure  3.  Information  Help  Screen  Example 


SYSTEM  OPERATION 


AFIT  Researc 

h  llanagenent  Systen  (ARMS) 

llain  Menu 

— >  1 

Research  Topic  Selection  Subsysten 

2 

Research  Products  Reuse  Subsysten 

3 

Research  Hanagenent  Subsysten 

4 

Database  Adninistration  Subsysten 

5 

Exit 

Make  your  choice:  millllH 

Press  0  on  the  keypad  <KPO>  for  help — ensure  NUlfLOCK  is  on  •»» 

Sun  Jul  26  (H:3'»:21  1992  OSC  DBG  Replace  flRnS  (ARMS  ) 


Figure  4.  ARMS  Main  Menu 


Figure  4  shows  the  menu  displayed  after  a  successful  login  to  the 
ARMS.  The  four  subsystems  listed  in  the  menu  are  designed  to  provide 
information  that  is  intended  to  aid  student  researchers,  faculty 
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members,  and  research  management  personnel.  A 
subsystem  and  its  operation  is  provided  below. 


further  discussion  of  each 


Selection  Subsystem  f RTSS)  -  Through  the 
categorization  of  theses  and  automation  of  the  current  research  topics 
book,  the  RTSS ' s  goal  is  to  provide  student  researchers  with  the 
capability  to  review  available  information  in  a  more  focused  and 
expedient  manner.  The  on-line  information  contained  in  the  RTSS's 
tables  allows  a  researcher  to  review  the  complete  abstract  of  an  .AFIT 
thesis  and  should  assist  them  in  determining  if  a  more  detailed  review 
of  the  document  is  warranted. 

The  menu  in  Figure  5  lists  four  theses  categories  on  which  queries 
of  theses  and  their  abstracts  can  be  based.  The  fifth  menu  option 
allows  for  the  query  and  display  of  research  topics  which  are  either 
internally  generated  by  faculty  members  or  requests  for  research 
received  from  other  DoD  agencies.  In  each  case,  the  search  criteria  for 
this  version  of  the  prototype  is  limited  to  subject  term  criteria. 

Two  examples  of  queries  from  this  menu,  one  to  review  a  thesis  and 
its  abstract  and  another  to  review  a  topic  and  its  abstract,  are 
provided  to  assist  you  in  conducting  your  own  queries.  You  are 
encouraged  to  exercise  these  examples  in  order  to  understand  the 
operation  of  the  system. 


Research  Topic  Selection  Subsystem 

Main  Menu 


— >  1  Reuieu  All  Theses  Records 

Z  Reuieu  Continuing  Studies  Records 
3  Reuieu  Ongoing  Theses  Records 
'4  Reuieu  Sponsored  Theses  Records 

5  Reuieu  11^  Research  Requests 

6  Return  to  Preuious  Wenu 


(lake  your  choice: 

«««»  Press  0  on  the  keypad  <KPO>  for  help — ensure  HUtlLOCK  is  on 


Sun  Jul  26  04:40:18  1992 


OSC  DBG 


Replace 


ARnS  (RTHAIN  ) 


Figure  5.  Research  Topic  Selection  Subsystem  Main  Menu 


Querying /Reviewing  ^  Thesis  Record 


Step  1.  Selection  option  1  from  the  RTSS  main  menu  The  query  display 
in  Figure  6  should  be  on  the  screen. 

Step  2.  You  now  have  two  choices:  ( i)  enter  a  subject  term  (a  one-. 

two-,  or  three-word  descriptive  pnrase)  to  query  the  system  on 
or  (2)  press  Esc-v  to  reveal  a  .look-up  tabl^-  with  all  possibb"' 
values  for  tliesis  subject  For  the  pnipose  ot  this 


example,  press  Esc-v. 
appear  on  the  screen. 


The  look-up  table  in  Figure  7  should 


Step  3.  Following  the  directions  on  the  screen,  use  the  UP  and  DOWN 
ARROW  keys  (or  KP4  and  KPS)  to  move  to  the  desired  subject 
term.  Press  F4  when  ready  to  select  an  item  and  return  to  the 
main  form.  Select  SPARE  PARTS  for  this  example  and  press  F4  . 
The  display  should  match  Figure  8 . 

Step  4 .  Press  FI  to  execute  the  query  on  this  subject  term.  The  thesis 
information  record  in  Figure  9  should  appear  on  the  screen. 

Step  5.  Press  KP6  to  view  the  complete  abstract  for  this  thesis.  The 
text  screen  shown  in  Figure  10  should  now  be  on  the  screen. 

Page  forward  in  this  text  file  by  pressing  RETURN. 


Step  6 .  Press  KP4  to  see  if  there  is  another  record  matching  this 
criteria.  If  there  is  not,  you  may  return  to  the  menu  by 
pressing  F4  or  you  may  request  another  query  by  pressing  KP2  to 
return  to  the  screen  in  Figure  8 . 


====:;===  querv  all  theses 

========  SEIARCH  CRITERIA 

SUBJECT  TERn:HH^^^^H| 
DECREE  PROCRAn  ID:|i 
AUTHOR'S  LAST  l1AnE:BH|^H 
ADMISOR'S  LAST  MAnEt^H^H 


THIS  PAHEL  IS  DESIGNED  TO  ALLIW  TOO  TO  QUERY  THESES 
BASED  ON  THE  ABOUE  SEARCH  CRITERIA.  HOUEUER,  THIS 
UERSION  OF  THE  PROTOTYPE  IS  L INI TED  TO  JUST  SUBJECT 
TERN  SEARCHES. 


PRESS  <KPe>  FOR  HELP.  <F1>  TO  QUERY,  <F4>  TO  QUIT 


F^ntcr  SUBJECT  TERN  tn  qucrij  nn  nr  type  Esc-u  to  select  fron  a  look-up  table 


Char  Node :  Rep  lace  Paqe  1  Count : 

Figure  6.  'Review/Query  All  Theses’  Search  Criteria  Block 
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Figure  7.  Subject  Term  Look-Up  Table  Display 


SUBJECT  TERM: 

DEGREE  PROGRRn  ID:^ 
AUTHOR'S  LAST  HAHE: 
ADUISOR'S  LAST  HAME;| 


QUERY  ALL  THESES 
SEARCH  CRITERIA 


KPARE  PARTS 


Char  node:  Replace  Paqe  1 


Count:  "0 


Figure  8.  'Review/Query  All  Theses’  Search  Criteria  Block 
As  Filled  in  by  the  Look-Up  Table 
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Abstract 

This  research  assessed  the  performance  of  the  Spare  Parts 
for  the  Actiuation  of  Relocated  Systems  (SPARES)  forecast  model 
used  to  develop  the  spares  requirements  forecast  for  the  August 
1988  activation  of  the  174TFU  at  Syracuse  ANGB  NV.  SPARES  uas 
developed  by  the  Air  Force  Logistics  Management  Center  in  August 
1988  to  replace  existing  Standard  Base  Supply  System  (SBSS) 
forecasting  procedures.  SPARES  uses  mission  change  data  (MCD) 
from  five  similar-size  source  bases  to  determine  the 
probability  of  future  demand  (PFD)  for  items  at  the  gaining  base. 
Before  implementing  SPARES  in  the  SBSS>  forecast  performance  must 
be  neasur^  and  model  weaknesses  identified  and  corrected. 

SPARES  correctly  forecasted  7Z  percent  of  the  demanded  items 
when  a  PPD  of  ZO  percent  was  used;  however,  58  percent  of  the 
items  forecasted  did  not  have  subsequent  demands.  SPARES 
forecasted  69Z  items  which  had  less  than  two  customer  demands  at 
the  five  source  bases  combined.  This  indicates  either  the 
model's  program  coding  is  incorrect  or  deficiencies  exist  in 
theoretical  program  logic.  Deficiencies  in  the  FICD  collection 
system  also  had  an  impact  on  SPARES  . ;rfomance.  Based  on  these 
findings,  SPARES  program  coding  and  logic  as  well  as  the  MCD 
collection  system  must  be  reviewed  before  SPARES  is  implemented 


Figure  10.  Thesis  Abstract  Display 


Querying /Reviewing  ^  Topic  Record 

Step  1.  Select  option  5  from  the  RTSS  main  menu.  The  query  display  in 
Figure  11  should  be  on  the  screen. 

Step  2.  You  have  two  choices:  (1)  enter  a  subject  term  (a  one-,  two-, 

or  three-word  descriptive  phrase)  to  query  the  system  on  or  (2) 
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press  Esc-v  to  reveal  a  look-up  table  with  all  possible  values 
for  thesis  subject  term.  For  this  example,  type  in 
MAINTENANCE  MANAGEMENT. 


Step  3.  Press  FI  to  execute  the  query.  The  topic  information  record  in 
Figure  12  should  appear  on  the  screen. 

Step  4 .  Press  KPL  to  view  the  second  page  of  the  topic  information 

record  (as  shown  in  Figure  13) .  Note  that  you  may  return  to 
page  1  from  page  2  by  pressing  KP2 . 

Step  5.  Press  KP6  to  view  the  abstract  for  this  topic.  The  text  screen 
shown  in  Figure  14  should  now  be  on  the  screen.  Press  RETURN 
to  page  forward  through  the  displayed  text  file. 


Step  6 .  Press  KP4  to  see  if  there  is  another  record  matching  the  given 
criteria.  If  there  is  not,  you  may  return  to  the  menu  by 
pressing  F4  or  you  may  request  another  query  by  pressing  KP2  to 
return  to  the  screen  in  Figure  11. 


====  QUERY  TOPICS  ==== 
====  SEARCH  CRITERIA  ==== 

SUBJECT  TERn:BH^mBH^| 

TOPIC  ID  NR:^^B 

EXTERHAL  SOURCE :| 

NOniNATOR 


THIS  PANEL  ALLOWS  YOU  TO  QUERY  RESEARCH  TOPICS 
BASED  UPON  SELECTION  CRITERIA.  THESE  CRITERIA 
ARE  SUBJECT  TERN,  TOPIC  NUNBER,  EXTERNAL  SOURCE 
(YxN),  AND  NONINATOR'S  OFFICE  SYNBOL. 

THIS  PROTOTYPE  LINITS  THE  SELKTION  CRITERIA  TO 
SUBJECT  TERN  FOR  THE  PURPOSES  OF  THIS  TEST. 


PRESS  <KPe>  FOR  HELP.  <F1>  TO  QUERY,  <F4>  TO  QUIT 


Enter  SUBJECT  TERN  to  quf:ry  on  nr  type  Esc-u  to  seltart  from  a  look-tip  table 


Char  Node:  Replace  Paqe  1  Count:  «0 


Figure  11.  'Review/Query  New  Research  Requests'  Search  Criteria  Block 
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Depots  are  currently  losing  gouernnent  contracts  to  industry.  Uliat 
factors  nake  gouernnent  depots  less  responsiue  and  more  expensioe  tlian  our 
industrial  counterparts?  Background  can  address  the  changes  that  haoe  led 
to  this  conpctitiuc  cnuironnent.  Uc  arc  auare  that  OC-ALC  recently  lost  an 
engine  repair  contract,  llethodology  nay  be  conducted  as  a  case  study  of 
contract  efforts  our  depots  haue  lost. 

—  Press  BETUW1  to  return  to  SQL»Forns  — 


Figure  14 .  Topic  Abstract  Display 


Research  Products  Reuse  Subsystem  (RPRSl  -  The  RPRS  represents  an 
adaptation  of  the  'software  reuse'  concept,  which  is  defined  as  the  use 
of  previously  developed  and/or  acquired  software  components  (source  code 
modules,  design  descriptions,  documentation,  and  so  on)  in  a  new 
development  project.  The  application  of  this  technique  to  the  thesis 
yields  several  potential  components  for  reuse.  Currently,  the  process 
of  locating  such  items  is  very  tedious  and  time-consuming  since  only  the 
thesis  document  is  cataloged.  The  RPRS  provides  the  framework  for 
cataloging  research  components  and  allows  for  on-line  storage  of  an 
abstract  describing  the  component,  and  in  some  cases,  an  electronic  copv 
of  the  component  itself. 

An  example  query  is  now  provided  to  assist  you  in  conducting  your 
own  queries .  You  are  encouraged  to  exercise  this  example  in  order  to 
understand  the  operation  of  the  system. 


Querying  /Reviewing  ^  ,CginES?n,Sn£  Record 


Step  1.  Select  option  2  from  the  ARMS  main  menu.  The  query  display  in 
Figure  15  should  be  on  the  screen. 

Step  2.  You  now  have  two  choices:  (1)  enter  a  component  type  or  (2) 

press  Esc-v  to  reveal  a  look-up  table  with  all  possible  values 
for  component  type.  Press  Esc-v  and  the  look-up  table  shown  in 
Figure  16  should  appear. 

Step  3.  Following  the  directions  on  the  screen,  use  the  UP  and  DOWN 
ARROW  keys  (or  KP4  and  KPS)  to  move  to  the  desired  component 
type.  Press  F4  when  ready  to  select  an  item  and  return  to  the 
main  form.  Select  PROGRAM  for  this  example.  The  display 
should  match  the  one  in  Figure  17. 


Step  4 .  Press  FI  to  execute  the  query  on  this  component  type  A 

component  information  record  should  appear.  For  the  purpose  of 
this  example,  press  KP4  twice  to  move  to  the  record  shown  in 
Figure  18 . 


Step  5 .  Press  KP6  to  view  the  abstract  for  this  component .  The  text 
screen  shown  in  Figure  19  should  now  be  on  the  screen .  Page 
through  the  text  by  pressing  RETURN  until  you  return  to  the 
component  information  record. 

Step  6.  A  copy  of  this  component  has  been  entered  and  is  electronically 
stored  on-line.  Press  KP3  now  to  view  it.  The  screen  in 
Figure  20  should  appear  displaying  a  SAS  program.  Press  RETURN 
to  proceed  through  the  text  until  you  return  to  the  component 
information  record. 
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step  7,  Press  KP4  to  see  if  there  is  another  record  matching  the  given 
criteria.  If  there  is  not,  you  may  return  to  the  menu  by 
pressing  F4  or  you  may  request  another  query  by  pressing  KP2  to 
return  to  the  screen  in  Figure  15  . 


querv  coupoments 

======  SEARCH  CRITERIA 

COnPOHEHT  TVPE  :■■■■■ 


THIS  PANEL  PRESENTS  AM  OPTICW  TO  QUERV  COTIPOMEMTS 
OMLV  BY  TYPE.  FUTURE  UERSIOMS  OF  THE  PROTOTYPE 
COULD  INCORPORATE  FURTHER  SEARCH  CRITERIA  I TENS 
SUCH  AS:  BY  SUBJECT  TERN,  BY  GRADUATE  PROGRAtl  ID, 
AND  A  MUNBER  OF  OTHERS. 


PRESS  <KPO>  TO  GET  HELP.  <F1>  TO  QUERV.  <F4>  TO  QUIT 


Enter  cowponent  type  to  query  on  or  type  Esc-u  to  select  fron  a  look-up  table 


Char  Node:  Replace  Page  1  Count: 


Figure  15.  'Review/Query  Components'  Search  Criteria  Block 


figure  16  Component  Types  Look-Up  Table  Display 
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Figure  17.  'Review/Query  Components'  Search  Criteria  Block  As 
Filled  in  by  the  Look-Up  Table 


COtIPOMEMT  IMFORmilOM 


DftTE  SUBniTTED: 


COnPOMENT  TITLE 


flS  Pragrao 


M2iW»F  1  T^Gin/LSV/gi  S-27 


POC  DEPftRTnEMT:i 


C0nP0MEMT;2 


OTHER  COrtlENTS 


PRESS  <KP«>  TO  GET  HELP,  <KP3>  TO  UIEU  COTIPOMENT,  <KP6>  TO  UlEU  ABSTRACT 


w  Char  Rode:  Replace  Pane  Z 


Figure  18.  Component  Information  Record 


Count:  5 
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PrograM  Abstract 

The  regression  analyses  perforned  by  this  progran  sought  to  identify 
the  key  relationships  anong  the  variables:  Bed-Size.  Annual  Medical  Supply 
Purchases.  Medical  Supply  FTEs.  Official  Inventory,  and  Warehouse  Size. 
Three  separate  categories  (Models)  of  analyses  uere  perforned  for  the 
dependent  variables.  These  dependent  variables  uere  FIE  (full-tine- 
equivalent)  reductions,  official  inuentory  reductions,  and  uarehouse 
reductions. 

—  Press  RETURN  to  return  to  SQL»ForMS  — 


Figure  19.  Component  Abstract  Display 


DATA  BARS: 

INPUT  BEDS  PURCH  PREFTE  PREINU  PREWIS  POSTFTE  POSTINU 

POSTUHS  CHGFTE  CH6INU  CH6UHS  PCIFTE  PCTINU  PCTMHS  @6: 
ARRAT  X  fl4}  BEDS—PCIUHS; 

ARRAV  L  (H>  LEEDS  LPURCH  LPREFTE  LPREINU  LPREUHS  LPOSTFTE 

LPOSTINU  LPQSTUHS  LCH6FTE  LCHGINU  LCH6UHS  LPCTFTE 
LPCTINU  LPCTUHS; 

DO  I  =1  TO  14; 

L  (I>=L06(X  <11) : 

END: 

DROP  I; 

CARDS: 


575  zeeeeeee  iz 
.583  .963  .938 

554606 

8666 

5 

26066 

566 

7 

534666 

7566 

356  7666666  33 

.364  .978  .977 

556606 

13066 

19 

12666 

366 

12 

538666 

12760 

176  1756969  14 

.143  .846  .938 

250606 

8660 

12 

46660 

560 

2 

216666 

7500 

46  134637  1.5 

.6661  .964  .822 

55606 

563 

1.5 

2666 

166 

.6661 

53860 

463 

46  126666  2 

.256  .975  .940 

116666 

2560 

1.5 

2886 

150 

.5 

107200 

2350 

ress  RETURN  to  continui 


Figure  20.  Text  Display  of  a  Component 


Research  Management  Subsystem  ( RMS )  -  The  RMS  is  designed  to 
provide  a  convenient  source  of  management  information  concerning  the 
AFIT/LS  student  research  program.  The  capability  of  this  subsystem  is 
limited  in  this  version  of  the  prototype  due  to  a  lack  of  detailed 
requirements.  Figure  21  shows  some  examples  of  the  types  of  information 
that  the  developers  feel  should  be  in  a  mature  RMS. 

The  first  three  options  in  the  menu  shown  in  Figure  21  were 
developed  for  operational  test  purposes.  The  first  item,  'Review 
Continuing  Research  Information'  is  similar  to  the  capability  provided 
in  the  RTSS  and  contains  only  one  example  record  that  may  be  queried. 

The  second  and  third  items  on  this  menu  provide  information  that  might 
be  equally  valuable  to  student  researchers,  faculty  members,  and 
research  management  personnel.  Example  queries  of  these  two  options  are 
provided  to  assist  you  in  conducting  your  own  queries . 
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Research  Hanagenent  Subsystem 

riain  tienu 


Reuieu  Contitiuing  Research  Infomation 
Reuieu  Research  Sponsorship  Information 
Reuieu  Thesis  ftduisor  Qualifications 
Reuieu  Thesis  Completion  Status 
Reuieu  Research  Publication  Infomation 
Return  to  Preuious  ftenu 


riake  yo«.ir  cltoice: 

*»H*  Press  0  on  the  keypad  <KPO>  for  help — ensure  HUHLOCX  is  on 


u  Sun  Jul  26  05:21:19  1992 


OSC  DBG 


Replace  0RnS  (RnnBlM  ) 


Figure  21.  Research  Management  Subsystem  Main  Menu 


Querying /Reviewing  q,  SEOa  Sgl  Record 

Step  1,  Select  option  2  from  the  RMS  main  menu.  The  query  display  in 
Figure  22  should  be  on  the  screen. 

Step  2.  You  now  have  two  choices:  (1)  enter  a  sponsor's  organization 

and  office  symbol  (SPONSOR_ORG_OFCSYM)  to  query  on  or  (2)  press 
Esc-v  to  reveal  a  look-up  table  with  all  possible  values  for 
SPONSOR_ORG_OFCSYM .  Press  Esc-v  and  the  look-up  table  shown 
in  Figure  23  should  appear. 

Step  3 .  Following  the  directions  on  the  screen,  use  the  UP  and  DOWN 

ARROW  keys  (or  KP4  and  KPS)  to  move  to  the  desired  'sponsor.' 
Press  F4  when  ready  to  select  an  item  and  return  to  the  main 
form.  Select  HQ  TAC  for  this  example  and  press  F4 .  The 
display  should  match  the  one  in  Figure  24 . 

Step  4 .  Press  FI  to  execute  the  query  on  this  term.  The  sponsor 

information  record  in  Figure  25  should  appear  on  the  screen. 

Step  5 .  Press  KP4  to  see  if  there  is  another  record  matching  the  given 
criteria.  If  there  is  not,  you  may  return  to  the  menu  by 
pressing  F4  or  you  may  request  another  query  by  pressing  KP2  to 
return  to  the  screen  in  Figure  24 . 
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Figure  22.  'Review  Research  Sponsorship  Information'  Search 
Criteria  Block 


Figure  23 .  Sponsor  Look-Up  Table  Display 
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Figure  24.  'Review  Research  Sponsorship  Information'  Search 
Criteria  Block  As  Filled  in  by  the  Look-Up  Table 


SPOnSOR  INFORmTlON 


SPONSOR  POC: 
SPONSOR  ORG: 
ADDRESS : 


>1  Udii  fi.  HcCrea 
TAG 


(PRESS:  <KPe>  FOR  HELP.  <KP4>  TO  UIEM  NEXT  RECORD.  <F4> 

10 

RETURN  TO  THE  NENU) 

Char  Node:  Replace  Page  Z 


Figure  25.  Sponsor  Information  Record 


Count: 
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^  Thesis  Advisor 


Record 


Step  1. 


Select  option  3  from  the  RMS  main  menu. 
Figure  26  should  be  on  the  screen. 


The  query  display  in 


Step  2 . 


You  have  two  choices;  (1)  enter  a  valid  interest  area  that  you 
want  to  query  on  or  (2)  press  Esc-v  to  reveal  a  look-up  table 
with  all  possible  values  for  advisor  interest  areas .  Press 
Esc-v  and  the  look-up  table  shown  in  Figure  27  should  appear. 


Step  3. 


Following  the  directions  on  the  screen,  use  the  UP  and  DOWN 
ARROW  keys  (or  KP4  and  KPS)  to  move  to  the  desired  'interest 
area. '  Press  F4  when  ready  to  select  an  item  and  return  to  the 
main  form.  Select  ACQUISITION  LOGISTICS  for  this  example  and 
press  F4 .  The  display  should  match  the  one  in  Figure  28 . 


Step  4 . 


Press  FI  to  execute  the  query.  The  thesis  advisor  information 
record  in  Figure  29  should  appear  on  the  screen. 


Step  5 . 


Press  KP4  to  see  if  there  is  another  record  matching  the  given 
criteria.  If  there  is  not,  you  may  return  to  the  menu  by 
pressing  F4  or  you  may  request  another  query  by  pressing  KP2  to 
return  to  the  screen  in  Figure  26 . 


Figure  26.  'Review  Thesis  Advisor  Qualification  Information' 
Search  Criteria  Block 


I 
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V  Char  node:  Replace  Page  1  Ci 


Figure  27.  Interest  Area  Look-Up  Table  Display 


=====  THESIS  ROMISOR  SEARCH  CRITERIA  ===== 


INTEREST  area: 


FlCgUISITlUH  LOGISTICS 


ADUISOR'S  LAST  HANE: 
ADUISOR’S  ORG/'OFCSVN: 
AOgiSItWI  STATUS: I 


THIS  PANEL  IS  DESIGNED  TO  ALLOU  VOU  TO  QUERY  ADUISOR 
INFORNATION  BASED  ON  THE  ABOUE  SEARCH  CRITERIA.  HOU- 
EUER,  THIS  UERSION  OF  THE  PROTOTYPE  IS  LIMITED  TO 
'INTEREST  AREA'  SEARCHES. 


PRESS  <KPe>  FOR  HELP.  <F1>  TO  QUERY.  <r4>  TO  QUIT 


tf!nti:r  INTEREST  fiREfl  to  niinri)  on  or  tijpi;  F.sc-o  to  skIcj:!  f ron  a  look-up  table: 


Char  Node:  Replace  Page  1 


Count:  «0 


Figure  28.  'Review  Thesis  Advisor  Qualification  Inforinat ion '  Search 
Criteria  Block  as  Filled  in  by  the  Look-Up  Table 
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Figure  29.  Thesis  Advisor  Information  Record 


Database  Administration  Subsystem  -  This  subsystem  was  designed  to 
provide  personnel  assigned  database  administration  responsibilities  with 
the  capabilities  to  perform  their  job.  Two  primary  sets  of  activities, 
as  shown  in  Figure  30,  may  be  done  in  this  subsystem- -record 
manipulation  and  special  SQL  queries. 


RRns  Database  Adninistration  Subsysten 

rtain  rienu 


— >  1  Add/Change,^Oelete  Records 

Z  Perfom  Special  Queries 
3  Return  to  Preuious  Henu 


haVe  gour  choice: 

<«M*  Press  0  on  the  keypad  <KP0>  for  help — ensure  MUflLOCK  is  on 


Sun  Jul  Z6  65:Z6:S2  199Z 


OSC  DBG 


Replace  ARMS  (DARAIN  ) 


Figure  30.  Database  Administration  Subsystem  Main  Menu 
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To  ensure  the  integrity  of  the  ARMS,  only  personnel  with  the 
proper  level  of  access  are  capable  of  viewing  the  menus  required  to 
access  the  Database  Administration  Subsystem's  capabilities.  No 
operational  test  evaluators  will  have  access  to  this  subsystem. 


EXITING  THE  SYSTEM 

Pressing  5  at  the  ARMS  Main  Menu  will  allow  you  to  reach  the 
LANCER  system  prompt.  At  that  time,  you  may  either  logout  (by  typing 
LOGOUT)  or  return  to  your  home  directory  (by  typing  HOME),  You'll  be 
returned  to  the  LS_LAN  NOVELL  menu  after  logging  out  of  LANCER. 


FINAL  COMMENTS 

Please  ensure  you  document  all  of  your  comments  on  the  prototype 
evaluation  form.  Your  written  comments  will  help  the  researchers 
appropriately  document  needed  improvements  or  positive  aspects  of  the 
system. 
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Appendix  Qj.  Prototype  Test  Results  for  New  students  Test 


INTRODUCTION 

Questions  were  rated  according  to  the  following  scale: 

1  -  strongly  agree  4  -  disagree 

2  -  agree  5  -  strongly  disagree 

3  -  neutral  N  -  not  applicable 

Evaluators  were  divided  into  two  categories  based  on  their  answer  to 
question  one,  inexperienced  computer  and  database  users  (ratings  3,  4, 
and  5)  and  experienced  computer  and  database  users  (ratings  1  and  2). 
Listed  below  are  the  questions  provided  to  the  new  students,  the  number 
of  individuals  who  gave  the  indicated  rating,  and  the  representative 
percentages  for  each  rating  per  category. 

GENERAL  INFORMATION  QUESTIONS 

1.  I  consider  myself  knowledgeable  about  the  general  operation  of 
computers  and  database  management  systems . 

1  2  3  4  5 

3(10%)  13(45%)  7(24%)  6(21%)  0(  0%) 

2.  The  menu's  help  screens  were  self-explanatory  and  provided  me  with 
enough  information  to  begin  using  the  system. 


1 

2 

3 

4 

5 

> 

•J 

Inexperienced  User 

1(  8%) 

10(83%) 

1( 

8%) 

0(  0%) 

0( 

0%) 

0( 

0%) 

Experienced  User 

2(13%) 

11(69%) 

1( 

6%) 

2(13%) 

0( 

0%) 

0( 

0%) 

Total 

3(11%) 

21(75%) 

2( 

7%) 

2(  7%) 

0( 

0%) 

0( 

0%) 

SUBSYSTEM  EVALUATION  QUESTIONS 

3.  I  felt  confident  operating  this  subsystem  using  only  the  on-screen 
help  facilities  (field/option-specific  help  bar,  separate 
instruction  blocks,  etc.): 

Research  Topic  Selection 


1 

2 

3 

4 

5 

N 

Inexperienced  User 

1(  8%) 

9(69%) 

1(  8%) 

2(15%) 

0( 

0%) 

0( 

0%) 

Experienced  User 

1{  6%) 

13(81%) 

2(13%) 

0(  0%) 

0( 

0%) 

0{ 

0%) 

Total 

2(  7%) 

22(76%) 

3(10%) 

2(  7%) 

0( 

0%) 

0( 

0%) 

Research  Products  Reuse 

1 

2 

3 

4 

5 

N 

Inexperienced  User 

1(  8%) 

9(69%) 

1(  8%) 

2(15%) 

0( 

0%) 

0( 

0%) 

Experienced  User 

2(13%) 

11(69%) 

1(  6%) 

2(13%) 

0( 

0%) 

0( 

0%) 

Total 

3(10%) 

20(69%) 

2(  7%) 

4(14%) 

0( 

0%) 

0( 

0%) 

I  found  this  subsystem  easy 

to  learn 

and  use 

Research  Topic  Selection 

1 

2 

3 

4 

5 

N 

Inexperienced  User 

6(46%) 

6(46%) 

1(  8%) 

0(  0%) 

0( 

0%) 

0( 

0%) 

Experienced  User 

4(25%) 

11(69%) 

1(  6%) 

0(  0%) 

0{ 

0%) 

0( 

0%) 

Total 

10(34%) 

17(59%) 

2(  7%) 

0(  0%) 

0( 

0%) 

0( 

0%) 
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Research  Products  Reuse 


1 

2 

3 

4 

5 

N 

Inexperienced  User 

4(31%) 

8(62%) 

1(  8%) 

0( 

0%) 

0( 

0%) 

0( 

0%) 

Experienced  User 

2(13%) 

11(69%) 

3(19%) 

0( 

0%) 

0( 

0%) 

0( 

0%) 

Total 

6(21%) 

19(66%) 

4(14%) 

0( 

0%) 

0( 

0%) 

0( 

0%) 

5.  I  feel  the  type  of  automated  information  provided  by  this  subsystem 
could  help  (or  could  have  helped)  me  more  efficiently  conduct  a 
research  study: 

Research  TQPic  Selection 


1 

2 

3 

4 

5 

N 

Inexperienced  User 

9(69%) 

4(31%) 

0(  0%) 

0( 

0%) 

0(  0%) 

0(  0%) 

Experienced  User 

10(63%) 

5(31%) 

1(  6%) 

0( 

0%) 

0(  0%) 

0(  0%) 

Total 

19(66%) 

9(31%) 

1(  3%) 

0( 

0%) 

0(  0%) 

0(  0%) 

Research  Products  J 

Reuse 

1 

2 

3 

4 

5 

N 

Inexperienced  User 

8(62%) 

5(38%) 

0(  0%) 

0( 

0%) 

0(  0%) 

0  (  0%) 

Experienced  User 

10(63%) 

5(31%) 

K  6%) 

0( 

0%) 

0(  0%) 

0(  0%) 

Total 

18(62%) 

10(34%) 

K  3%) 

0( 

0%) 

0(  0%) 

0  (  0%) 

I  would  use  (or  would  have 

used)  this  subsystem 

for 

research 

1  work  if 

it  were  fully  operational: 

Bsaaaxgb  T<?pid  Sglg-g.tlQn 

1 

2 

3 

4 

5 

N 

Inexperienced  User 

11(85%) 

2(15%) 

0(  0%) 

0( 

0%) 

0(  0%) 

0  (  0%) 

Experienced  User 

13(81%) 

3(19%) 

0(  0%) 

0( 

0%) 

0(  0%) 

0(  0%) 

Total 

24(83%) 

5(17%) 

0(  0%) 

0( 

0%) 

0(  0%) 

0(  0%) 

Research  Products  j 

Reuse 

1 

2 

3 

4 

5 

N 

Inexperienced  User 

10(77%) 

3(23%) 

0(  0%) 

0( 

0%) 

0(  0%) 

0(  0%) 

Experienced  User 

12(75%) 

4(25%) 

0(  0%) 

0( 

0%) 

0(  0%) 

0(  0%) 

Total 

22(76%) 

7(24%) 

0(  0%) 

0( 

0%) 

0(  0%) 

0(  0%) 

OVERALL  SISIEM  EVALUATION 

7.  I  liked  the  following  features  about  the  subsystems  I  used  (circle 
all  that  apply) : 

a.  screen  displays  (screen  organization) 

b.  functions  (what  the  subsystems  do) 

c.  processing  speed  (system  response  time) 

d.  data  (applicability,  breadth) 

e.  written  instructions 

f.  on-line  help  instructions 


a 

b 

c 

d 

e 

f 

Inexperienced  User 

8 

(62%) 

10(77%) 

1(  8%) 

6(46%) 

5(38%) 

6 

(46%) 

Experienced  User 

13 

(81%) 

14(88%) 

5(31%) 

12(75%) 

7(44%) 

5 

(31%) 

Total 

21 

(72%) 

24(83%) 

6(21%) 

18(62%) 

12(41%) 

11 

(38%) 
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8 .  The  following  features  of  the  subsystems  I  used  need  to  be  improved 
(circle  all  that  apply) ; 

a.  screen  displays  (screen  organization) 

b.  functions  (what  the  subsystems  do) 

c.  processing  speed  (system  response  time) 

d.  data  (applicability,  breadth) 

e .  written  instructions 

f.  on-line  help  instructions 

a  b  c 

Inexperienced  User  0(  0%)  1(  8%)  3(23%) 

Experienced  User  1(  6%)  1(  6%)  7(44%) 

Total  1(  3%)  2(  7%)  10(34%) 

9 .  I  used  the  APIT  Research  Management  System: 

a .  less  than  15  minutes 

b.  15  to  30  minutes 

c.  30  minutes  to  one  hour 

d.  more  than  one  hour 


a 

b 

c 

d 

Inexperienced  User 

4(31%) 

7(54%) 

2(15%) 

0( 

0%) 

Experienced  User 

1(  6%) 

12(75%) 

3(19%) 

0( 

0%) 

Total 

5(17%) 

19(66%) 

5(17%) 

0( 

0%) 

Note:  1.  One  inexperienced  user  did  not  answer  question  two. 

2.  The  percentages  listed  in  questions  seven  and  eight  are  based 
upon  the  total  number  of  respondents  in  each  group. 

3.  Due  to  rounding,  the  percentage  totals  for  several  questions 
do  not  equal  100%. 


d  e  f 

2(15%)  0(  0%)  5(38%) 

4(25%)  2(13%)  5(31%) 

6(21%)  2(  7%)  10(34%) 
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Appendix  H :  Prototype  Test  Results  for  Current  Students  Test 


INTRODUCTION 

Questions  were  rated  according  to  the  following  scale: 

1  -  strongly  agree  4  -  disagree 

2  -  agree  5  -  strongly  disagree 

3  -  neutral  N  -  not  applicable 

Evaluators  were  divided  into  two  categories  based  on  their  answer  to 
question  one,  inexperienced  computer  and  database  users  (ratings  3,  4, 
and  5)  and  experienced  computer  and  database  users  (ratings  1  and  2). 
All  members  of  this  sample  indicated  they  were  experienced  users. 
Listed  below  are  the  questions  provided  to  the  current  students,  the 
number  of  individuals  who  gave  the  indicated  rating,  and  the 
representative  percentages  for  each  rating . 

GENERAL  INFORMATION  ilUESIIQIta 

1.  I  consider  myself  knowledgeable  about  the  general  operation  of 
computers  and  database  management  systems . 

1  2  3  4  5 

6(33%)  12(67%)  0(  0%)  0(  0%)  0(  0%) 

2.  The  menu's  help  screens  were  self-explanatory  and  provided  me  with 
enough  information  to  begin  using  the  system. 

1  2  3  4  5  N 

3(17%)  11(61%)  1(  6%)  3(17%)  0(  0%)  0(  0%) 

SUBSYSTEM  EVALUATION  QUESII0H£ 

3.  I  felt  confident  operating  this  subsystem  using  only  the  on-screen 
help  facilities  (field/option-specific  help  bar,  separate 
instruction  blocks,  etc.): 


1  2 

3 

4 

5 

Research 

Topic  Selection: 

2(11%)  14(78%) 

1(  6%) 

K  6%) 

0( 

0%) 

0( 

0% 

Research 

Products  Reugg : 

2(11%)  15(83%) 

0(  0%) 

K  6%) 

0( 

0  % ) 

0( 

0% 

Research 

Management : 

1(  6%)  15(83%) 

0(  0%) 

K  6%) 

0( 

0%) 

1( 

6% 

4 .  I  found  this  subsystem  easy  to  learn  and 

use : 

1  2 

3 

4 

5 

N 

Research 

Topic  Selection: 

5(28%)  10(56%) 

1(  6%) 

2(11%) 

0( 

0%) 

0  1 

0% 

Research 

Products  Reusg : 

4(22%)  11(61%) 

1(  6%) 

2(11%) 

0( 

0%) 

0( 

0% 

Rgggaroh 

Management : 

4(22%)  10(56%) 

1(  6%) 

2(11%) 

0( 

0%) 

il 

6  6 

5 .  1  feel  the  type  of  automated  information 

provided  by  this 

sub: 

3  V  S 

tern 

could  help  (or  could  have 

helped)  me  more  efficiently 

conduct 

a 

research 

study : 

1  2 

3 

4 

5 

N 

Research 

Topic  Selection: 

14(78%)  3(17%) 

1(  6%) 

0(  0%) 

0( 

0%) 

0( 

0% 

Ressaroh 

Products  Reuse : 

10(56%)  7(39%) 

1(  6%) 

0(  0%) 

0( 

0%) 

0( 

0% 

Research 

Management : 

8(44%)  7(39%) 

2(11%) 

0(  0%) 

0( 

0%) 

1( 

6  % 

H-1 
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I  vould  use  i;or  '.vould  have  used)  this  subsystem  for  research  •.■•'ork 
It  were  fully  operational: 


Research  Topic  Selection : 
Research  Products  Reuse : 
Research  Management : 


1  2 
15(83%)  3(17%) 

13(72%)  4(22%) 
10(56%)  5(28%) 


0(  0%)  0(  0%) 
1(  6%)  0(  0%) 
1(  6%)  1(  6%) 


D  h 

0  (  0  %  )  0  (  0  %  } 
0  (  0  %  J  0  (  0  %  ) 
0  (  0  %  )  i  (  6  %  ) 


OVERALL  SYSTEM  EVALUATION 


I  liked  the  following  features  about  the  subsystems  I  used  (circle 
all  that  apply) : 


a.  screen  displays  (screen  organization):  14(78%) 

b.  functions  (what  the  subsystems  do):  16(89%) 

c.  processing  speed  (system  response  time):  6(33%) 

d.  data  (applicability,  breadth):  11(61%) 

e.  written  instructions:  9(50%) 

f.  on-line  help  instructions:  13(72%) 


8 .  The  following  features  of  the  subsystems  I  used  need  to  be  improved 
(circle  all  that  apply): 


a.  screen  displays  (screen  organization):  5(28%) 

b.  functions  (what  the  subsystems  do):  0(  0%) 

c.  processing  speed  (system  response  time):  11(61%) 

d.  data  (applicability,  breadth):  6(33%) 

e.  written  instructions:  2(11%) 

f.  on-line  help  instructions:  6(33%) 


9.  I  used  the  AFIT  Research  Management  System: 


a  . 

less  than 

15 

minutes : 

3(17%) 

b . 

15  to  30  minutes: 

9(50%) 

c . 

30  minutes 

to 

one  hour: 

6(33%) 

d. 

more  than 

one 

hour : 

0(  0%) 

N’ote:  1.  The  percentages  listed  in  questions  seven  and  eight  are  based 
upon  the  total  number  of  respondents  in  the  sample, 

2,  Due  to  rounding,  the  percentage  totals  for  several  questions 
do  not  equal  100%  . 
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Appgn^ix  Xi.  PcatQtyp^  Test  Result?  Iqj  Faculty  Test 


INTRODUCTION 

Questions  were  rated  according  to  the  following  scale: 

1  -  strongly  agree  4  -  disagree 

2  -  agree  5  -  strongly  disagree 

3  -  neutral  N  -  not  applicable 

Evaluators  were  divided  into  two  categories  based  on  their  answer  to 
question  one,  inexperienced  computer  and  database  users  (ratings  3,  4, 
and  5)  and  experienced  computer  and  database  users  (ratings  1  and  2). 
Listed  below  are  the  questions  provided  to  the  new  students,  the  number 
of  individuals  who  gave  the  indicated  rating,  and  the  representative 
percentages  for  each  rating  per  category. 

GENERAL  INFORMATION  QUESTIONS 

1.  I  consider  myself  knowledgeable  about  the  general  operation  of 
computers  and  database  management  systems . 


1 

2 

3  4 

5 

3(30%) 

4(40%) 

2(20%)  1(10 

%)  0( 

0%) 

The  menu's  help  screens  were  self-explanatory  and 

provided 

me 

with 

enough  information 

to  begin 

using  the  system. 

1 

2  3 

4 

5 

N 

Inexperienced  User 

1(33%) 

1(33%)  0(  0%) 

1(33%) 

0(  0%) 

0( 

0%) 

Experienced  User 

0(  0%) 

6(86%)  0(  0%) 

1(14%) 

0(  0%) 

0( 

0%) 

Total 

1(10%) 

7(70%)  0(  0%) 

2(20%) 

0(  0%) 

0( 

0%) 

SUBSYSTEM  EVALUATION  QUESTIONS 

3.  I  felt  confident  operating  this  subsystem  using  only  the  on-screen 
help  facilities  (field/option-specific  help  bar,  separate 
instruction  blocks,  etc.): 

Research  Topic  Selection 


1 

2 

3 

4 

5 

N 

Inexperienced  User 

0(  0%) 

3(100%) 

0(  0%) 

0(  0%) 

0  (  0%) 

0( 

0%) 

Experienced  User 

2(29%) 

3(43%) 

2(29%) 

0(  0%) 

0(  0%) 

0( 

0% ) 

Total 

2(20%) 

6(60%) 

2(20%) 

0  (  0%) 

0(  0%) 

0( 

0%) 

Research  Products  Reusg 

1 

2 

3 

4 

5 

N 

Inexperienced  User 

0(  0%) 

2(67%) 

0(  0%) 

1(33%) 

0(  0%) 

0( 

0%) 

Experienced  User 

2(29%) 

2(29%) 

2(29%) 

1(14%) 

0  (  0%) 

0( 

0%) 

Total 

2(20%) 

4(40%) 

2(20%) 

2(20%) 

0(  0%) 

0( 

0%) 

Research  Management 

1 

2 

3 

4 

5 

N 

Inexperienced  User 

0(  0%) 

3(100%) 

0(  0%) 

0(  0%) 

0(  0%) 

0( 

0%) 

Experienced  User 

1(14%) 

3(43%) 

3(43%) 

0(  0%) 

0(  0%) 

0( 

0%) 

Total 

1(10%) 

6(60%) 

3(30%) 

0(  0%) 

0  (  0%) 

0( 

0%) 
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I  found  this  subsystem  easy  to  learn  and  use; 


1 

2 

3 

4 

5 

N 

Inexperienced  User 

0(  0%) 

2(67%) 

1(33%) 

0( 

0%) 

0( 

0%) 

0( 

0%) 

Experienced  User 

4(57%) 

2(29%) 

1(14%) 

0( 

0%) 

0( 

0%) 

0( 

0%) 

Total 

4(40%) 

4 (40%) 

2(20%) 

0( 

0%) 

0( 

0%) 

0{ 

0%) 

Research  Products  Reuse 

1 

2 

3 

4 

5 

N 

Inexperienced  User 

0(  0%) 

1(33%) 

2(67%; 

0( 

0%) 

0( 

0%) 

0( 

0%) 

Experienced  User 

3(43%) 

3(43%) 

1(14%) 

0( 

0%) 

0( 

0%) 

0( 

0%) 

Total 

3(30%) 

4 (40%) 

3(30%) 

0( 

0%) 

0( 

0%) 

0( 

0%) 

Research  Management 

1 

2 

3 

4 

5 

N 

Inexperienced  User 

0(  0%) 

1(33%) 

2(67%) 

0( 

0%) 

0( 

0%) 

0( 

0  % ) 

Experienced  User 

3(43%) 

2(29%) 

2(29%) 

0( 

0%) 

0( 

0%) 

0{ 

0%) 

Total 

3(30%) 

3(30%) 

4(40%) 

0( 

0%) 

0( 

0%) 

0( 

0%) 

I  feel  the  type  of  automated  information  provided  by  this  subsystem 
could  help  (or  could  have  helped)  me  more  efficiently  conduct  a 
research  study; 


Research  Iapi.c  Seli 

Inexperienced  User 
Experienced  User 
Total 


Experienced  User 
Total 


Inexperienced  User 
Experienced  User 
Total 


1 

2 

3 

4 

5 

N 

2(67%) 

0(  0%) 

0(  0%) 

0( 

0%) 

0( 

0%) 

1(33%) 

2(29%) 

3(43%) 

1(14%) 

0( 

0%) 

0( 

0%) 

1(14%) 

4(40%) 

3(30%) 

1(10%) 

0( 

0%) 

0( 

0%) 

2(20%) 

;use 

1 

2 

3 

4 

5 

N 

2(67%) 

0(  0%) 

0(  0%) 

0( 

0%) 

0( 

0%) 

1(33%) 

3(43%) 

2(29%) 

1(14%) 

0( 

0%) 

0( 

0%) 

1(14%) 

5(50%) 

2(20%) 

1(10%) 

0( 

0%) 

0( 

0%) 

2(20%) 

1 

2 

3 

4 

5 

N 

2(67%) 

0(  0%) 

0(  0%) 

0( 

0%) 

0( 

0%) 

1(33%) 

2(29%) 

4(57%) 

0(  0%) 

0( 

0%) 

0( 

0%) 

1(14%) 

4(40%) 

4 (40%) 

0(  0%) 

0( 

0%) 

0( 

0%) 

2(20%) 

I  would  use  (or  would  have  used)  this  subsystem  for  research  work  if 
it  were  fully  operational; 


Research  Topid 

Inexperienced  User 
Experienced  User 
Total 


Experienced  User 
Total 


Inexperienced  User 
Experienced  User 
Total 


1 

2 

3 

4 

5 

N 

2(67%) 

0(  0%) 

0(  0%) 

0( 

0%) 

0( 

0%) 

1(33%) 

2(29%) 

1(14%) 

2(29%) 

0( 

0%) 

0( 

0%) 

2(29%) 

4(40%) 

1(10%) 

2(20%) 

0( 

0%) 

0( 

0%) 

3(30%) 

•use 

1 

2 

3 

4 

5 

N 

1(33%) 

0(  0%) 

2(67%) 

0( 

0%) 

0( 

0%) 

0(  0%) 

4(57%) 

0(  0%) 

1(14%) 

0( 

0%) 

0( 

0%) 

2(29%) 

5(50%) 

0(  0%) 

3(30%) 

0( 

0%) 

0( 

0%) 

2(20%) 

1 

2 

3 

4 

5 

N 

2(67%) 

1(33%) 

0(  0%) 

0( 

0%) 

0( 

0%) 

0  (  0%) 

1(14%) 

2(29%) 

2(29%) 

0( 

0%) 

0( 

0%) 

2(29%) 

3(30%) 

3(30%) 

2(20%) 

0( 

0%) 

0( 

0%) 

2(20%) 
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OVERALL  SYSTEM 


7.  I  liked  the  following  features  about  the  subsystems  I  used  (circle 
all  that  apply) : 

a.  screen  displays  (screen  organization) 

b.  functions  (what  the  subsystems  do) 

c.  processing  speed  (system  response  time) 

d.  data  (applicability,  breadth) 

e.  written  instructions 

f.  on-line  help  instructions 


a 

b 

c 

d 

e 

f 

Inexperienced  User 

3(100%) 

1(33%) 

1(33%) 

2(67%) 

0(  0%) 

2(67%) 

Experienced  User 

5(71%) 

5(71%) 

3(43%) 

2(29%) 

5(71%) 

3(43%) 

Total 

8(80%) 

6(60%) 

4(40%) 

4(40%) 

5(50%) 

5(50%) 

8.  The  following  features  of  the  subsystems  I  used  need  to  be  improved 
(circle  all  that  apply) : 

a.  screen  displays  (screen  organization) 

b.  functions  (what  the  subsystems  do) 

c.  processing  speed  (system  response  time) 

d.  data  (applicability,  breadth) 

e.  written  instructions 

f.  on-line  help  instructions 

a  b  c  d  e  f 

Inexperienced  User  0(  0%)  2(67%)  1(33%)  0(  0%)  2(67%)  2(67%) 

Experienced  User  1(14%)  1(14%)  2(29%)  5(71%)  0(  0%)  3(43%) 

Total  1(10%)  3(30%)  3(30%)  5(50%)  2(20%)  5(50%) 

9 .  I  used  the  AFIT  Research  Management  System: 

a .  less  than  15  minutes 

b.  15  to  30  minutes 

c.  30  minutes  to  one  hour 

d.  more  than  one  hour 

abed 
Inexperienced  User  1(33%)  1(33%)  1(33%)  0(  0%) 

Experienced  User  0(  0%)  3(43%)  4(57%)  0(  0%) 

Total  1(10%)  4(40%)  5(50%)  0(  0%) 


Note:  1.  The  percentages  listed  in  questions  seven  and  eight  are  based 
upon  the  total  number  of  respondents  in  each  group. 

2.  Due  to  rounding,  the  percentage  totals  for  several  questions 
do  not  equal  100%. 
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Appendix  il-  SummarY  q1  Written  Commgntg  from  Test  Evaluators 


Over  thirteen  single-spaced  pages  of  comments  were  received  from  the 
three  samples  of  operational  test  evaluators.  The  topical  lists  below 
contain  the  most  significant  and  prevalent  comments. 

1.  £uture  Rasgarch  Recommendations 

a.  Accessibility  of  data  could  be  enhanced.  Wildcard  and  keyword 
search  capabilities  would  be  beneficial.  In  addition,  speed  searching 
within  the  look-up  tables  (which  involves  the  movement  of  the  cursor  to 
a  set  of  records  that  match  a  typed  letter)  would  increase  the  usability 
of  this  feature. 

b.  A  personal  computer  (PC)  version  might  be  more  practical  and 
should  be  explored.  Also,  given  the  increasing  use  of  contact  disk 
read-only  memory  (CD-ROM),  can  the  ARMS  be  placed  on  such  a  medium  and 
used  on  a  PC? 

c.  Provide  users  with  the  capability  to  print  information  they  are 
viewing . 

d.  Research  Management  System: 

(1)  Provide  capability  under  'Thesis  Advisor  Qualifications' 
option  to; 

(a)  search  by  advisor's  last  name; 

(b)  list  all  faculty  with  a  matching  interest  area; 

(2)  List  all  known  beneficiaries  of  a  thesis  study  on  the 
'Sponsor  Information  Record'  rather  than  just  the  sponsor. 

(3)  Add  e-mail  address  data  item  field  to  the  sponsor  and 
advisor  records . 

e.  Research  Topic  Selection  Subsystem: 

(1)  Provide  the  capability  to  list  all  faculty  members 
interested  in  a  particular  topic. 

(2)  Provide  the  capability  to  search  theses  by  author's  name. 


2 .  General  Comments 

a.  Faculty  interface  and  comments  concerning  potential  follow-on 
work  would  be  valuable  and  provide  "good"  topics  for  study. 

b.  Great  potential  for  saving  time  if  the  system  is  given  adequate 
information  to  cover  a  wide  range  of  topics  and  theses. 

c.  I  liked  the  ability  to  view  an  abstract  for  a  reuse  product. 
Also,  the  availability  of  a  look-up  table  to  view  a  list  of  examples  was 
exceptionally  helpful. 

d.  I  see  promise  in  what  you're  trying  to  do.  Key  factors  which 
will  determine  success  include : 
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(1)  Keeping  the  database  current 

(2)  Ensuring  proper  abstracts  are  submitted  with  the  thesis 
(plus  components)  on  disk  for  easy  entry  into  the  system. 

( 3 )  Improving  the  user  interface . 

e.  I'm  not  sure  that  the  reuse  feature  is  going  to  be  a  boon  to 
AFIT  research.  I  believe  that  a  large  part  of  the  research  learning  is 
the  development  of  these  questionnaires.  The  "questionnaire-brand" 
research  is  not  generally  the  kind  of  thing  that  will  keep  AFIT  alive 
and  respected  as  a  research  institution. 

f.  This  program  is  only  a  small  part  of  the  research  management 
task. 

g.  Without  a  solid,  well -maintained  database,  this  system  is  of 
limited  utility.  Even  with  a  good  database  it  still  has  holes. 

h.  Use  of  the  ARMS  could  be  extremely  beneficial  in  selecting  a 
thesis  topic.  The  abstract  and  component  lists  are  very  helpful  and 
informative . 

i.  This  really  sounds  like  something  the  library  should/could 
manage  effectively. 

j.  The  on-line  questionnaires,  surveys,  programs,  etc,  would  be  a 
strong  asset  as  long  as  they  could  be  easily  converted  to  soft -copy 
format . 


a.  Suggest  you  add  an  opening  information  screen  before  the  main 
menu  explaining  the  purpose  of  the  system. 

b.  On-line  help  was  somewhat  limited,  but  the  list  of  keys  and 
functions  screen  was  useful. 

c.  Function/keypad  keys’  abbreviated  definitions  should  be  shown  at 
the  bottom  of  all  applicable  screen. 


4 .  eolicy 

a .  AFIT  needs  to  provide  better  research  support  to  students  and 
the  Air  Force .  Our  ESC  and  ACC  sponsors  have  provided  close  to  two 
million  dollars  for  AFIT  research  in  our  class,  but  I  don't  think  AFIT 
will  follow-up  with  them  for  future  research.  Students  receive  very 
little  start-up  support  on  topic  selection  or  committee  formation. 

b.  Policy  considerations  should  be  given  to  having  AFIT  students 
input  the  information  into  the  system  for  their  part  of  the  thesis 
effort . 

c.  Is  the  ARMS  worth  it?  What  is  the  resource  cost?  Are  the 
present  methods  totally  inadequate? 

d.  The  system  seems  valuable;  particularly  for  the  recall  of 
reusable  research  "components."  However,  there  will  have  to  be  strong 
input  rules  for  consistency. 
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e.  The  key  to  the  usefulness  of  this  system  will  be  its  currency. 
A  thorough  consideration  of  policy  issues  along  these  lines  is 
essential . 

f.  In  order  for  this  system  to  work,  policy  will  need  to  be 
enforced  at  the  student  and  faculty  levels  to  ensure  information  is 
submitted  and  cataloged  in  the  system. 


5. 

a.  System  ran  too  slow  to  evaluate  realistically. 

b.  Speed  was  fine  with  a  limited  database,  but  how  will  it  be  with 
500  or  more  records? 


6 .  User  Friendliness 

a.  After  the  first  few  queries,  using  the  system  was  almost  second 
nature . 

b.  The  "Thesis  Information  Record"  award  codes  should  be  explained 
somewhere  or  listed  out  completely. 

c.  I  think  some  of  your  key  selections  should  be  more  "user 
friendly."  Why  use  Esc-V,  KP4,  etc,  when  you  could  use  just  plain 
number  or  letter  or  function  keys  (e.g.,  N  for  next  record,  Q  for 
inquiry,  B  for  backup  to  previous  display,  M  for  main  men  H  for  help, 
etc)  ? 

d.  Currently,  the  process  of  using  Esc-V  and  F4,  to  display  and 
select  from  a  look-up  table,  does  not  automatically  perform  a  query. 
Instead,  I'm  returned  to  the  previous  query  screen  where  I  must  press 
another  key,  FI,  to  perform  the  query.  The  return  to  the  query  screen 
step  should  be  removed  unless  it  will  perform  some  added  function  (like 
multi- field  searches)  in  the  future. 

e.  If  keys  could  be  used  that  don't  require  the  "MUM  LOCK"  to  be 
on,  the  system  would  be  more  user  friendly. 

f.  The  'Component  Information  Record'  doesn't  include  the  title  for 
the  thesis  it  came  from.  Inclusion  of  this  information  would  make 
looking  for  the  thesis  in  library  easier. 

g.  It  would  help  if  <KP#>  and  <F#>  macros  were  dissimilar  '  s  .  For 
example,  KP4  and  F4  are  used  a  lot.  I  mixed  up  their  uses  a  lot. 

h.  Users  should  have  access  to  the  thesis  title  and  abstract 
anywhere  they  are  looking  at  information  about  a  specific  thesis.  This 
will  give  them  idea  where  the  item  (such  as  a  research  product  for 
reuse)  came  from  (its  context)  or  where  it  was  used  (its  utility) . 


7.  Mritten  instructions 


a . 

b. 

c . 


Draft  copy  of  user's  guide  was  informative. 

May  want  to  consider  putting  all  written  instructions 
User  manual  is  okay,  but  could  be  more  extensive. 


on-line . 
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d.  Providing  a  simple  list  of  all  tables  and  fields  in  the  user's 
guide  would  enhance  the  understandability  and  use  of  the  system. 

e.  It  would  be  nice  to  have  a  one-page  "rosetta  stone"  help  sheet. 
Face  it,  users  won't  take  the  time  to  read  the  manual. 


J-4 


UPDATED 


FUNCTIONAL  DESCRIPTION 


FOR  THE  PROPOSED 


AFIT  RESEARCH  MANAGEMENT  SYSTEM  (ARMS) 


(Current  as  of:  20  Aug  92) 


FUNCTIONAL  DESCRIPTION 
TABLE  OF  CONTENTS 

SECTION  1.  GENERAL  * 

1.1  Purpose  of  the  Functional  Description  * 

1.2  Project  References  * 

1.3  Terms  and  Abbreviations  * 

SECTION  2.  SYSTEM  SUMMARY  * 

2 . 1  Background  * 

2.2  Objectives  * 

2 . 3  Existing  Methods  and  Procedures  * 

2 . 4  Proposed  Methods  and  Procedures  * 

2 . 5  Assumptions  and  Constraints  * 

SECTION  3.  DETAILED  CHARACTERISTICS  * 

3 . 1  General  Performance  Requirements  * 

3 . 2  Functional  Area  System  Functions  * 

3.3  Inputs -Outputs  * 

3.4  Data  Base  Characteristics  * 

3 . 5  Failure  Contingencies  * 

3 . 6  Security  * 

SECTION  4 .  DESIGN  DETAILS  * 

4 . 1  Implemented  Requirements  * 

4 . 2  Data  Structures  * 

4 . 3  Menus  and  Screen  Displays  * 

4.4  Help  Facilities  * 

SECTION  5.  ENVIRONMENT  * 

5 . 1  Equipment  Environment  * 

5 . 2  Support  Software  Environment  * 

5 . 3  Interfaces  * 

5 . 4  Security  * 

SECTION  6.  COST  FACTORS  * 

SECTION  7 .  SYSTEM  DEVELOPMENT  PLAN  * 

7 . 1  Initial  Prototype  Development  and  Results  * 

7.2  Follow-On  Recommendations  * 

Attachment  1  -  Prototype  ARMS  Data  Dictionary  * 

Attachment  2  -  Prototype  ARMS  Menu/Forms  Tree  * 

Note;  Normal  page  numbering  was  removed  to  a  '  w  this  document  to  be 
appropriately  formatted  into  this  thesis. 


K-2 


SECTION  1 .  GENERAL 


Purpose  al  Functional  Description.  This  Functional  Description 
for  the  prototype  AFIT  Research  Management  System  (ARMS)  was  written  to 
provide : 

A.  System  requirements  which  will  serve  as  a  basis  for  mutual 
understanding  between  the  future  users  and  the  developers 

B.  Information  on  performance  requirements,  improvements, 
impacts,  and  the  system  development  status 

C.  A  basis  for  system  test  and  evaluation 

1,2  Rgfargncgs. 

A.  AFIT  Thesis:  AFIT/GSS/LSC92D- 5 ,  "Development  of  a  Prototype 
Air  Force  Institute  of  Technology  (AFIT)  Research  Management 
System, "  by  Captains  David  Schaaf  and  Carl  Scott 

B.  DoD  STD-7935,  "Automated  Data  Systems  Documentation,"  1  Nov  82 
1  ■  3  Tgmg  ^nd  Abbreviations 

A.  ARMS  -  AFIT  Research  Management  System 

B.  Automated  Requirements  -  System  requirements  which  can  be 
implemented  in  the  ARMS  software  suite 

C.  Component  -  A  definable  part  of  a  system 

D.  Continuing  Research  Stream  -  Research  which  builds  upon  the 
results  of  previous  studies 

E.  Continuing  Study  -  A  research  effort  that  serves  as  a  follow- 
on  to  a  previously  conducted  study. 

F.  DE  -  School  of  Civil  Engineering  and  Services 

G.  EN  -  School  of  Engineering 

H.  Faculty-Centered  Research  -  research  initiated,  managed,  and 
perpetuated  by  a  faculty  member 

I .  LS  -  School  of  Systems  and  Logistics 

J.  Nonautomated  Requirements  -  System  requirements  which  cannot 
be  implemented  as  part  of  the  ARMS  software  suite  (for 
example,  policy  changes) 

K.  Ongoing  Thesis/Study  -  A  study  that  is  still  in  progress. 

L.  Prototype  -  A  working  model  of  a  computer  system  which  is  used 
for  testing  the  viability  of  a  solution  to  a  problem  area 

M.  Research  Product  -  component  of  the  research  process  generated 
and  used  as  part  of  a  research  project.  (For  example,  data 
collection  instruments,  data,  statistical  models,  computer 
programs,  and  computer  program  documentation) 

N.  Reuse  -  The  application  of  existing  solutions  to  the  problems 
of  systems  development 
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O.  Software  -  Computer  programs,  procedures,  associated 
documentation,  and  data  pertaining  to  the  operation  of  a 
computer  system  and  peripherals 

P.  Software  Component  -  An  element  of  software  (code  module, 
design  document,  etc.)  that  performs  a  definitive  function 

Q.  Software  Reuse  -  The  use  of  previously  developed  and/or 
acquired  software  components  in  a  new  development  project 

R.  System  -  A  collection  of  components  organized  to  accomplish  a 
specific  function  or  set  of  functions 
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SECTION  2.  SYSTEM  SUMMARY 

2 ■ 1  Background.  The  idea  for  this  system  was  derived  from  the 
experiences  of  two  students  in  the  School  of  Systems  and  Logistics  (LS)  . 
The  difficulties  of  determining  what  research  topics  are  important  to 
the  Air  Force  and  DoD,  as  well  as  the  complexity  of  scoping  a  workable 
research  project,  led  them  to  initiate  a  research  project  that  would  aid 
future  students. 

This  project  is  based  on  an  emerging  computer  science  technique 
called  software  reuse.  This  technique  is  commonly  defined  as  the  use  of 
previously  acquired  and  developed  concepts  and  objects  in  a  new 
situation.  In  the  area  of  software  development,  this  would  include 
items  such  as  source  code  modules,  program  architectures,  software 
documentation,  and  a  number  of  other  products.  The  intuitive  benefits 
of  this  technique  are  in  the  areas  of  productivity  (cost  and  time 
avoidance),  quality,  and  reliability.  To  be  effectively  implemented, 
reuse  requires  an  extensive  effort  to  determine  what  and  how  products 
should  be  cataloged  into  a  library  system.  The  library  system  then 
allows  the  products  to  be  located,  reviewed  for  applicability  to  a  new 
project,  and  subsequently  reused. 

Current  efforts  in  the  area  of  reuse  are  focused  on  applying  the 
technique  to  specific  "domains.”  This  project  supports  the  intention  of 
these  efforts  by  adapting  and  evaluating  reuse  in  the  "research  domain." 
Using  the  original  goal  of  building  a  research  products  reuse  system, 
the  student  researchers  found  that  there  are  many  management  benefits  to 
be  gained  by  employing  such  a  system.  This  insight  led  them  to  expand 
the  scope  of  the  system's  goals  to  those  listed  in  the  next  paragraph. 

2 . 2  Goals .  The  major  goals  of  the  prototype  ARMS  are  to: 

A.  Enhance  the  student  researcher's  capabilities  to  select  and 
scope  a  research  problem  which  is  vital  to  the  Air  Force  and 
DoD. 

B.  Improve  student  researcher's  productivity  by  adapting  and 
evaluating  the  concept  of  reuse  to  the  research  domain. 

C.  Increase  management  efficiency  by  providing  a  collection  of 
data  which  can  be  used  to  efficiently  meet  reporting  needs. 

D.  Stimulate  an  increased  conduct  of  continuing  research  streams 
within  LS  and  DE. 

2... 3.  Existing  Methods  and  Procedures .  Similar  academic  research 
processes  are  conducted  by  two  of  the  three  schools  at  AFIT.  Currently, 
the  Schools  of  Systems  and  Logistics  (LS)  and  Civil  Engineering  and 
Services  (DE)  allow  students  to  select  their  own  research  topics;  while 
the  School  of  Engineering  (EN)  employs  an  approach  that  fosters 
continuing  research  streams.  Aside  from  this  difference,  the 
description  of  the  existing  methods  and  procedures  provided  below 
applies  to  all  three  schools . 

It  is  important  to  note  that  modeling  the  entire  academic  research 
domain  for  the  initial  prototype  ARMS  would  have  been  an  insurmountable 
task  during  the  short  research  period  afforded  AFIT  graduate  students. 
Therefore,  only  three  major  facets  of  the  domain  were  examined  during 
the  initial  study:  research  topic  selection,  research  product  reuse,  and 
research  management.  Figure  1  provides  an  illustration  of  the  major 
elements  and  their  interaction  within  the  current  research  environment . 
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Figure  1.  Context  Diagram  of  the  Current  AFIT  Research  Environment 


2.3.1  Topic  Selection .  AFIT  graduate  students  researching  possible 
thesis  topics  can  refer  to  several  resources.  Many  of  these  resources 
are  found  in  the  academic  library,  which  contains  a  wide  variety  of 
services  for  conducting  topical  literature  searches.  Also,  research 
directors  and  some  faculty  members  formally  and  informally  "advertise" 
potential  topics.  However,  it  is  not  always  clear  to  the  student 
researcher  which  topics  are  of  vital  interest  to  the  Air  Force  and  DoD . 

The  availability  of  thesis  advisors  during  the  critical  initiation 
phase  of  new  students '  research  activities  is  another  area  that  impacts 
topic  selection.  At  present,  students  in  the  initial  period  of 
selecting  and  scoping  a  suitable  problem  for  research,  compete  for 
thesis  advisors  with  students  who  are  in  the  final  stages  of  their 
projects.  This  situation  not  only  impairs  the  progress  of  new 
researchers,  but  places  an  immense  burden  on  the  faculty.  Hence,  thesis 
advisors  are  not  readily  available  for  consultation  until  after  Labor 
Day.  By  that  time,  students  within  the  LS  school  (and  in  some  cases  DE) 
are  nearing  completion  of  a  literature  review  assignment  for  the 
mandatory  COMM  687  (Theory  and  Practice  of  Professional  Communications) 
course.  Under  the  current  system,  the  potential  benefits  of  COMM  687 
are  not  fully  realized.  Students  without  a  well-defined  topic  may  spend 
valuable  time  researching  a  subject  unrelated  to  their  thesis. 

2.3.2  Research  Product  Reuse .  During  the  process  of  completing  their 
theses,  student  researchers  generate  a  number  of  products  to  ccllect  and 
analyze  data.  In  addition,  some  student  researchers  develop  software 
systems  or  other  end  products  as  a  result  of  their  efforts.  The 
documentation  of  such  items  is  embodied  within  theses  and  often  archived 
without  consideration  for  further  use.  (As  noted  above,  the  EN  school 
has  a  program  of  continuing  research  streams  that  reuses  products  from 
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past  studies.  However,  such  items  are  not  cataloged  or  made  available  to 
students  in  other  schools.)  Therefore,  research  products  reuse  is 
inhibited  in  part  by  the  difficulty  that  students  face  in  locating  the 
items  which  may  benefit  their  research  efforts.  Once  a  suitable  product 
for  reuse  is  located,  the  researcher  normally  must  recreate  it  using 
manual  methods . 

Based  on  the  concept  of  reuse,  student  researchers  potentially 
have  a  great  deal  to  gain  by  locating,  reviewing,  and  reusing  (in  part 
or  wholly)  quality  research  products  that  are  presently  underutilized. 
The  current  methods  of  locating  and  manually  reviewing  theses  might  be 
more  acceptable  if  students  had  a  greater  length  of  time  to  conduct 
their  research.  However,  the  current  12-15  month  start- to- finish  thesis 
process  puts  pressure  on  students  to  complete  thiir  research  projects 
expediently.  Improvements  in  locating  and  reviewing  products  could 
potentially  relieve  pressure  by  making  validated  products  readily 
available  for  reuse. 

2.3.3  Research  Management .  The  process  of  managing  academic  research 
is  accomplished  at  AFIT  by  the  research  directors  for  each  school.  As 
focal  points  for  summarizing  and  formally  reporting  their  school's 
research  efforts,  the  directors  use  a  number  of  automated  and 
nonautomated  procedures.  However,  none  of  these  procedures  have  a 
single  collection  point  for  data.  Such  a  data  base  would  offer  many 
potential  benefits. 

Faculty  members  at  each  school  who  serve  as  thesis  advisors  share 
responsibility  in  the  area  of  research  management.  In  particular,  the 
underlying  basis  for  a  quality  program  of  continuing  research  streams  is 
faculty- centered  research.  However,  due  to  the  short  tenure  of  many 
military  faculty  members,  the  promotion  and  longevity  of  continuing 
research  streams  is  somewhat  restricted.  The  capability  to  track  on¬ 
going  or  review  past  continuing  research  streams  could  produce  an 
improved  environment  for  similar  efforts  in  the  future. 

2 . 4  Proposed  Methods  and  Procedures .  This  section  outlines  the 
improvements  offered  by  the  proposed  AEIMS  and  describes  the  system's 
impact  on  the  present  research  process  at  AFIT.  Figure  2  pictorially 
shows  how  a  production  quality  ARMS  is  expected  to  interact  within  the 
research  environment. 

2.4.1  Summary  of  Improvements .  Student  researchers,  faculty  members, 
and  research  directors  will  be  provided  with  certain  improvements  due  to 
the  implementation  of  the  ARMS.  The  improvements  are  grouped  into  four 
categories:  general,  research  topic  selection,  research  product  reuse, 
and  research  management . 

2 . 4 . 1 . 1  General  Improvements .  The  automated  portion  of  the  proposed 
ARMS  will  use  a  data  base  management  system  to  store  and  process  the 
data  needed  to  meet  student  researcher,  faculty,  and  management 
requirements.  As  an  automated  and  integrated  source  of  data,  the  ARMS 
will  offer  an  information  sharing  capability  among  the  three  AFIT 
schools.  Additionally,  the  ARMS  will  provide  intangible  benefits  of 
using  a  data  base  management  system  such  as  automated  record-keeping, 
improved  trend  tracking,  standardized/tailored  reporting,  and  other 
capabilities . 

2 . 4 . 1 . 2  Research  Topic  Selection  Improvements .  The  ARMS  will  provide 
an  expedient  method  for  reviewing  abstracts  which  describe  past  and  on¬ 
going  AFIT  research  projects.  The  system's  implementation  will 
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potentially  alleviate  some  of  the  constraints  described  above  in  section 
2.3.1.  The  instinctive  advantages  of  using  an  automated  system, 
combined  with  the  resources  available  in  the  current  system,  will  help 
researchers : 

A.  Begin  the  process  of  selecting/formulating  a  researchable 
topic  earlier  in  the  academic  year. 

B.  Review  a  broader  range  of  research  topics  more  expediently  and 
efficiently . 

C.  Scope  their  selected  research  problem. 

D.  Select  topics  that  lend  themselves  to  longitudinal  studies. 
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E.  Investigate  the  application  of  research  designs  and 

methodologies  to  specific  types  of  studies. 

F.  Perform  studies  that  are  more  relevant  to  the  Air  Force  and 

DoD. 

In  addition  to  reviewing  past  and  on-going  AFIT  research  efforts, 
students  will  also  be  able  to  scan  new  topic  suggestions  using  the  ARMS. 

2 ■ 4.^1 -I  Research  Product  Reuse  Improvements .  The  ARMS  will  provide  an 
efficient  means  of  cataloging  research  products  into  a  "library  system" 
for  future  reuse.  The  resultant  library  system  will  allow  researchers 
to  expediently  locate,  review,  and  reuse  research  products  from  previous 
theses . 

2 . 4 . 1. 3 . 1  Locating  Products .  The  ARMS  will  allow  researchers  to  locate 
reusable  research  products  in  many  different  ways.  The  following  is  a 
list  of  key  search  methods  that  may  be  used  individually  or  in  a  number 
of  combinations : 

A .  Component  type . 

1.  Thesis  documents 

2.  Data  collection  instruments  such  as  surveys,  interview 
formats,  and  questionnaires 

3 .  Data  from  previous  collection  efforts 

4 .  Statistical  models  developed  to  analyze  collected  data 

5.  Computer  programs  such  as  decision  support  systems,  expert 
sy.stems,  and  other  application  systems 

6 .  Computer  program  documentation  such  as  functional 
descriptions,  design  documents,  source  code,  test  plans, 
and  user's  guides 

B.  Descriptive  subject  term  such  as  Acquisition  Management, 

Contract  Management,  or  Environmental  Engineering 

C .  School/department 

D .  Author  name 

E.  Subject/keyword(s) 

The  capability  to  locate  specific  products  for  reuse  will  be  a 
major  improvement  over  the  systems  that  are  now  available  to  AFIT 
researchers.  Currently,  most  of  the  systems  only  provide  students  with 
the  capability  to  locate  thesis  documents  and  manually  review  them  for 
available  research  products . 

2 . 4 ■ 1 . 3 . 2  Reviewing  Products .  After  the  ARMS  locates  reusable  products 
based  on  the  provided  criteria,  the  researcher  will  be  able  to  review  an 
abstract  for  each  candidate  product.  Each  abstract  will  provide  both  a 
description  and  a  reuse  history  of  the  respective  product .  Researchers 
will  also  be  able  to  further  review  a  copy  of  the  product  to  determine 
if  it  is  reusable  in  their  research  project.  Overall,  the  capacity  to 
review  abstracts  and  copies  of  research  products  immediately  after 
locating  them  will  save  researchers '  time . 

2 . 4 . 1 . 3 ■ 3  Reusing  Products .  The  current  method  of  reusing  research 
products  normally  requires  the  researcher  to  re-create  the  products 
manually.  For  example,  researchers  must  either  re-type  the  product  or 
become  proficient  at  using  an  electronic  scanner  with  optical  character 
reading  capability.  To  minimize  this  limitation,  the  ARJ-IS  will  provide 
the  researcher  with  an  option  to  obtain  an  electronic  media  copy  of  the 
product.  The  ability  to  obtain  a  printed  copy  of  the  products  and 
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respective  abstracts  will  also  be  available .  Combined  with  the  improved 
locating  and  reviewing  functions,  these  features  should  further  enhance 
the  productivity  of  student  researchers. 

2.4 .1.4  Research  Management  Improvements .  The  ARMS,  by  virtue  of  the 
detailed  information  it  is  to  contain,  will  strongly  support  many 
management  applications .  The  following  is  a  representative  list  of 
information/functions  that  can  be  automated  by  employing  this  system; 

A.  Thesis  status  tracking  data  such  as  initiation  date,  personnel 
involved,  topic,  and  completion  date. 

B.  Thesis  publication  data  to  periodicals,  DTIC,  and  other 
archives . 

C.  Research  sponsorship  data  to  include  agency,  point  of  contact, 
funding  amounts,  and  cost-avoidance  estimates. 

D.  Continuing  research  stream(s)  monitoring. 

E.  New  research  topic  screening/advertisement. 

In  designing  the  ARMS,  the  developers  will  review  the  structure  of 
existing  data  base  systems  used  by  research  management  personnel  to  the 
extent  that  information  is  provided  by  the  organizations  administering 
such  systems.  The  aim  of  this  approach  is  to  allow  for  the  transfer  of 
existing  data  into  the  ARMS . 

2.4.2  Summary  of  Impacts .  The  ARMS  will  provide  more  timely  and 
accurate  information  to  support  the  conduct  and  management  of  the  AFIT 
student  research  process .  The  following  paragraphs  discuss  some  of  the 
system's  major  impacts  in  existing  organizational  and  operational 
environments.  In  particular,  the  following  paragraphs  outline  some  of 
the  major  nonautomated  requirements  that  must  be  addressed  before  the 
ARMS  can  be  fully  implemented. 

2. 4. 2.1  Organizational  Impacts . 

A.  A  number  of  personnel  (quantity  to  be  determined)  will  be 
required  to  perform  data  entry  operations.  This  effort  could 
be  minimized  depending  on  how  the  policies  and  procedures  for 
sustaining  the  system  are  structured.  See  paragraph 

2. 4. 2. 2. A. 

B.  A  database/system  manager  should  be  appointed  within  each  of 
the  three  schools  to  answer  user  questions  and  manage  school - 
specific  implementation  details. 

C.  An  application  administrator  should  be  assigned  within  AFIT/SC 
to  maintain  the  ARMS  application. 

2 . 4 . 2 ■ 2  Operational  Impacts .  Several  policies  will  need  to  be 
developed  to  ensure  the  system  is  implemented,  operated,  and  maintained 
efficiently.  Specifically,  all  operational  areas  (student  researchers, 
faculty  members  (thesis  advisors),  and  researcher  directors)  impacted  by 
the  ARMS  should  have  defined  responsibilities.  The  following 
suggestions  should  be  considered  before  fully  implementing  the  system: 


A.  Require  student  researchers  to  submit  electronic  media  copies 
(diskette  or  other  suitable  means)  of  research  products  and 
abstracts  along  with  completed  theses.  This  requirement  would 
impose  a  minimal,  workload  on  students,  while  significantly 
decreasing  the  data  entry  burden  for  the  system. 
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B.  Assign  faculty  members  (thesis  advisors)  the  responsibilities 
of : 

1.  Evaluating  research  products  generated  during  student 
projects  for  inclusion  in  the  research  products  reuse 
subsystem.  This  decision  is  similar  to  the  one  that  is 
now  made  concerning  thesis  publication  and  distribution. 

2.  Reviewing  research  topics  and  generating  new  ones  for 
input  to  the  topic  selection  part  of  the  ARMS . 

C.  Task  the  research  management  staff  (each  school's  research 
director  and  their  personnel)  with  overall  ownership 
responsibilities  for  the  system.  Such  responsibilities  might 
include:  monitoring  the  system's  data  accuracy  and  validity; 
acting  as  the  liaison  between  users  and  the  application 
administrator  (AFIT/SC)  for  problem  resolution  and/or  system 
improvements;  and  managing  the  access  permissions  for  certain 
data  within  the  system. 

2 ■ 4 ■ 2 ■ 3  Developmental  Impacts .  Besides  designing  and  implementing  the 
data  structures,  control  programs,  and  initial  data  set  for  the 
prototype  ARMS,  the  developers  will  accomplish  the  following  tasks  as 
part  of  this  project: 

A-  Training  ("hands-on"  instruction)  will  be  conducted  for  all 
personnel  participating  in  the  operational  test  of  the 
prototype  ARMS . 

B.  User  guides/instruction  sheets  will  be  developed  for  the 
various  ARMS  applications  (subsystems) . 

C.  Program  maintenance  documentation  will  be  developed  to  ensure 
the  system  can  be  enhanced  in  the  future. 

2 ■ 5  Assumptions  and  Constraints .  The  following  key  assumptions  and 
constraints  apply  to  this  project: 

A.  The  ARMS  is  a  prototype  development  that  will  potentially 
undergo  iterative  refinement  in  future  research  efforts  or  be 
turned  over  to  AFIT/SCV  for  maintenance.  Therefore,  coding 
and  documentation  conventions  consistent  with  those  used  in 
other  AFIT  automation  systems  were  and  should  continue  to  be 
employed  whenever  possible. 

B.  The  project  was  limited  to  the  use  of  existing  AFIT  computing 
hardware  and  software. 

C.  The  prototype  system  was  developed  to  store  and  process 
unclassified  information  only. 
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SECTION  3.0  DETAILED  CHARACTERISTICS 


3 ■ 1  General  Performance  Requirements .  The  list  below  provides  general 
performance  requirements  that  the  automated  portion  of  ARMS  must  meet 
while  providing  the  improvements  and  functions  described  in  sections  2.4 
and  3.2. 

A.  Provide  formatted  displays  for  interactive  (on-line)  data 
entry . 

B.  Minimize  user  entries  by  providing  default  values  and  range 
boundaries  where  possible. 

C.  Provide  feedback  when  a  transaction  has  either  been  completed 
or  rejected. 

D.  Ensure  that  only  completed  transactions  are  stored  in  the 
database . 

E.  Provide  an  ad  hoc  query  and  reporting  capability  to  users  with 
special  needs  and  advanced  training . 

F.  Permit  the  generation  of  predefined  reports. 

G.  Permit  retrieval  of  data  by  the  user  from/to  terminals  or  to 
printers . 

H.  Provide  each  user  the  authority  to  access  records  and  data  in 
their  areas  of  responsibility. 

I.  Limit  each  user  to  specified  processing  functions  based  on 
assigned  responsibilities. 

J.  Provide  daily,  weekly,  and  nranthly  database  backup  capability. 

3.2  Systgm  FunctiQns./Requirements .  To  directly  meet  the  general 
improvements  listed  in  section  2.4,  the  automated  portion  of  ARMS  has 
three  major  subsystems:  the  research  topic  selection  subsystem  (RTSS), 
research  products  reuse  subsystem  (RPRS),  and  research  management 
subsystem  (RMS) .  A  fourth  subsystem,  the  database  administration 
subsystem  (DAS) ,  provides  system  raanagers/monitors  with  the  capability 
to  maintain  the  ARMS. 

3.2.1  Subsystem  Descriptions .  The  following  general  descriptions 
guided  the  development  of  each  subsystem: 

3 . 2 ■ 1 ■ 1  RTSS .  Through  the  categorization  of  theses  and  automation  of 
the  current  research  topics  book,  the  RTSS  provides  student  researchers 
with  the  capability  to  review  available  information  in  a  more  focused 
and  expedient  manner.  The  on-line  information  contained  in  the  RTSS ' s 
tables  permits  researchers  to  review  the  complete  abstract  of  an  AFIT 
thesis  to  help  them  determine  if  a  more  detailed  review  of  the  document 
is  warranted.  Four  categories  of  theses  and  automated  research  requests 
can  be  queried  and  reviewed  based  on  a  variety  of  criteria . 

3 . 2 ■ 1 ■ 2  RPRS .  The  RPRS  represents  an  adaptation  of  the  "software 
reuse"  concept,  which  is  defined  as  the  use  of  previously  developed 
and/or  acquired  software  components  (such  as  source  code  modules,  design 
descriptions,  documentation,  and  so  on)  in  a  new  development  project. 

The  application  of  this  technique  to  the  thesis  yields  several  potential 
components  for  reuse.  Currently,  the  process  of  locating  such  items  is 
very  tedious  and  time-consuming  since  only  the  thesis  document  is 
cataloged.  The  RPRS  provides  the  framework  for  cataloging  research 
components  and  allows  for  the  on-line  storage  of  an  abstract  describing 
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the  component,  and  in  some  cases,  an  electronic  copy  of  the  component 
itself . 

3 ■ 2 ■ 1 . 3  RMS ■  The  RMS  is  designed  to  provide  a  convenient  source  of 
management  information  concerning  the  AFIT/LS  student  research  program. 
The  initial  capabilities  of  this  subsystem  include  the  ability  to  query 
and  review  information  concerning  continuing  research  studies,  research 
sponsors,  and  thesis  advisor  interests/qualifications. 

3 ■ 2 ■ 1 ■ 4  DAS  ■  This  subsystem  is  designed  to  provide  personnel  assigned 
database  administration  responsibilities  with  the  capabilities  to 
perform  their  job.  Two  primary  sets  of  activities  may  be  done  in  this 
subsystem:  record  manipulation  and  special  queries. 

3.2.2  Subsystem  Requirements .  A  fully  functional  ARMS  should  meet  the 
following  automated  requirements  listed  by  subsystem. 

3 . 2^2- 1  RTSS  Requirements . 

3. 2. 2. 1.1  Provide  the  capability  to  perform  thesis  queries  based  on  the 
following  types  of  user- provided  criteria: 

A.  Subject  term  (Software  Development,  Supply,  Maintenance,  etc.) 

B.  School/department  (LSC,  LSR,  etc.) 

C.  Degree  program  designator  (GSS,  GLM,  etc.) 

D.  Author  last  name 

E.  Advisor  last  name 

F.  Title/subject  keyword 

G.  Status  (completed,  ongoing,  sponsored,  and  award-winning) 

H.  Date  (completion  year) 

I.  Continuing  study  designation  (yes/no) 

J.  Research  design/methodology  type 

K.  Combinations  of  A  through  K  above 

3. 2. 2. 1.2  Provide  the  capability  to  perform  new  research  request 
(topic)  queries  based  on  the  following  types  of  user-provided  criteria: 

A.  Subject  term  (Software  Development,  Supply,  Maintenance,  etc.) 

B.  Topic  identification  number 

C.  Title/subject  keyword 

D.  Source  designation  (internal/external) 

E.  Nominating  organization 

F.  Faculty  POC  last  name 

G.  Usage  status  (previously  used  or  still  unused) 

3. 2. 2. 1.3  Provide  screen  listings  of  information  records  and  associated 
textual  abstracts  for  records  retrieved  by  the  queries  described  above 
in  paragraphs  3. 2. 2. 1.1  and  3. 2. 2. 1.2. 
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3. 2. 2. 1.4  Permit  printing  of  screen  displays  to  a  user-designated 
printer.  Provide  the  capability,  where  feasible,  for  printing  summary 
lists  of  query  results. 

3 , 2 ■ 2 . 2  RPRS  Requirements . 

3. 2. 2. 2.1  Provide  the  capability  to  perform  thesis  queries  based  on  the 
following  types  of  user- provided  criteria: 

A.  Component  type  (Survey,  Program,  Interview,  etc.) 

B.  Subject  term  (Software  Development,  Supply,  Maintenance,  etc.) 
c.  School/department  (LSC,  LSR,  etc.) 

D.  Degree  program  designator  (GSS,  GLM,  etc.) 

E.  Component  POC  last  name 

F.  Title/subject  keyword 

G.  Combinations  of  A  through  P  above 

3. 2. 2. 2. 2  Provide  screen  listings  of  information  records,  associated 
textual  abstracts,  and  electronic  copies  of  components  for  records 
retrieved  by  the  queries  described  above  in  paragraph  3.2.22.1. 

3. 2. 2. 2. 3  Permit  printing  of  screen  displays  to  a  user-designated' 
printer.  Provide  the  capability,  where  feasible,  for  printing  summary 
lists  of  query  results. 

3. 2. 2. 2. 4  When  requested,  provide  researchers  with  an  electronic  copy 
of  requested  components  that  are  stored  on-line. 

3  ■  2  ■  2  .,3  Requirements  . 

3. 2. 2. 3.1  Provide  a  menu  of  predefined  options  to  review  research 
program  information  concerning: 

A.  Thesis  progress/completion  tracking 

B.  External  publication  of  studies  (in  periodicals,  DTIC,  etc.) 

C.  Continuing  research  streams  (current  and  past) 

D.  Research  sponsorship 

E.  Thesis  advisor  qualifications 

3. 2. 2. 3. 2  Provide  screen  listings  of  information  records  and  associated 
textual  abstracts  for  records  retrieved  by  the  queries  described  above 
in  paragraph  3. 2. 2. 3.1. 

3. 2. 2. 3. 3  Permit  printing  of  screen  display.s  to  a  user-designated 
printer.  Provide  the  capability,  where  feasible,  for  printing  summary 
lists  of  query  results  and  other  formatted  reports. 

3 . 2 . 2 . 4  DAS  Requirements . 

3. 2. 2. 4.1  Provide  a  menu  that  permits  the  system  administrator  and 
other  designated  representatives  to  add,  change,  and  delete  records  in 
the  system's  data  tables. 
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3. 2. 2. 4. 2  Provide  the  system  administrator  and  other  designated 
representatives  with  the  capability  to  perform  specialized  queries  not 
covered  in  the  system's  menu  structure. 

3.2.3  Other  Design  Considerations .  The  system  will  validate  inputs 
against  look-up  tables  and  ranges  where  possible.  This  will  allow  for 
the  immediate  rejection  of  invalid  data  before  it  can  be  stored  in  the 
database .  The  system  will  not  permit  the  mistyping  of  character 
information  or  numbers  in  situations  where  validation  is  possible.  When 
an  error  is  detected,  the  user  will  be  requested  to  re-enter  the 
incorrect  information  or  allowed  to  quit  the  input  operation. 

3 . 3  Inputs -Outputs .  The  input  of  data  into  the  ARMS  tables  will 
primarily  be  accomplished  through  the  keyboard  of  a  personal  computer  or 
other  virtual  display  terminal  connected  to  the  AFITNET.  The  ARMS  will 
also  provide  an  interface  for  transferring  data  from  selected  disk 
drives  of  connected  computers  and  terminals .  Outputs  from  the  system 
will  include  screen  displays,  printouts,  disk  files,  or  tape  files. 

(Note:  Specific  outputs  for  the  initial  prototype  were  limited  to  screen 
displays . ) 

3 . 4  Data  Base  Characteristics .  There  are  seventeen  types  of  records 
that  contain  the  information  needed  to  meet  the  streamlined  set  of 
requirements  implemented  in  the  initial  prototype  ARMS.  A  detailed 
description  of  the  data  elements  for  each  record  type  is  listed  in  the 
ARMS  Data  Dictionary  (Attachment  1) .  The  data  dictionary  is  meant  to 
provide  the  database  administrator  and  other  special  users  with  an 
understanding  of  the  system's  data  structures.  Casual  users  of  the 
system  are  shielded  from  such  information  by  a  series  of  menu-  and 
prompt-driven  interfaces. 

5  Failure  Contingencies .  Database  failures  for  the  ARMS  can  fall 
into  three  categories : 

A.  Transaction  Failure:  A  failure  of  a  single  transaction  of  the 
database,  usually  caused  by  a  data  error. 

B.  Software  Failure:  A  failure  of  the  database  management  system 
itself,  usually  caused  by  a  programming  error. 

C.  Hardware  Failure:  A  failure  of  the  system  hardware,  either 
recoverable  or  catastrophic.  Recoverable  errors  are  tv’pically 
power  outages  and  catastrophic  errors  usually  destroy  data  in 
the  database  requiring  a  complete  recovery  of  the  database 
from  a  backup  copy. 

The  methods  used  to  prepare  for  and  recover  from  these  failures  are  as 
follows : 

A.  Backup.  A  daily’,  weekly,  and  monthly  backup  of  the  VAX 
Cluster  is  done  by  the  operations  branch  of  AFIT/SC.  The 
scope  of  each  type  of  backup  is  as  follows: 

1.  Daily:  All  changes  made  to  any  files  since  the  previous 
day . 

2.  Weekly:  All  changes  made  to  any  files  since  the  previous 
week . 

3.  Monthly:  All  files  on  the  VAX  Cluster. 

4.  Weeknights :  All  data  stored  in  the  ORACLE  database. 


K-15 


B.  Rollback.  ORACLE  provides  the  ability  to  rollback  incomplete 
transactions  at  the  discretion  of  the  user.  Changes  to  the 
database  are  not  permanent  until  the  user  commits  them  to  the 
database . 

C.  Restart.  Programs  that  are  using  ORACLE  can  be  restarted 
after  a  catastrophic  failure  once  the  database  is  restored. 

In  the  case  of  a  catastrophic  failure,  the  changes  which  had 
not  yet  been  committed  to  the  database  are  automatically 
"rolled  back." 

3-.  6  Security .  The  initial  prototype  ARMS  will  be  developed  to  store 
and  handle  only  unclassified,  nonsensitive  data.  Additional  precautions 
for  handling  additional  types  of  data  may  be  required  during  future 
enhancement  efforts. 
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SECTION  4.  DESIGN  DETAILS  OF  CURRENT  VERSION 

4 ■ 1  Implemented  Requirements .  Listed  below  are  the  paragraph  numbers 
of  the  requirements  implemented  in  each  subsystem  for  the  current 
version  of  the  ARMS: 


ill  1 1 1 1  1 1 

Research  Topic  Selection  (RTSS) 

3. 2. 2. 1.1  subparagraphs  A,  G,  and  I; 

3. 2. 2. 1.2. A;  3. 2. 2. 1.3 

Research  Products  Reuse  (RPRS) 

Research  Management  (RMS) 

3. 2. 2. 3.1  subparagraphs  C,  D,  and  E; 

3. 2. 2. 3. 2 

Database  Administration  (DAS) 

In  addition,  the  input  validation  requirements  specified  in  3.2.3  were 
implemented,  where  applicable,  within  the  design  for  each  subsystem. 

4 . 2  Data  Structures .  As  noted  in  paragraph  3.4,  there  are  seventeen 
types  of  records  that  contain  the  information  needed  to  meet  the 
streamlined  set  of  requirements  implemented  in  the  initial  prototype 
ARMS.  A  detailed  description  of  the  data  elements  for  each  record  type 
is  listed  in  the  ARMS  Data  Dictionary  (Attachment  1) .  A  pictorial  view 
of  the  key  relationships  between  the  objects  corresponding  to  the  ARMS 
primary  tables  is  provided  in  Figure  3 . 

4 . 3  Menus  and  Screen  Displays .  After  completing  the  design  for  the 
ARMS  data  structures,  a  menu  structure  was  developed  to  incorporate  the 
selected  automation  requirements  listed  in  paragraph  4.1.  Attachment  2 
provides  a  tree  which  lists  the  layout  of  the  menu  structure  as  well  as 
the  corresponding  "forms"  developed  to  manage  the  system.  The  "forms" 
are  the  file  names  ending  with  ".INP"  listed  under  each  action-oriented 
menu  option.  Three  primary  types  of  screens  were  developed  for  the 
system:  the  "query"  screen  that  provides  the  user  with  a  "friendly" 
interface  to  find  records  of  interest;  the  "information  record"  display 
that  presents  the  records  retrieved  by  user-generated  queries;  and 
"text- format"  layouts  that  list  "information  record"  abstracts  and 
electronic  copies  of  components.  All  three  of  these  screens  types  are 
encapsulated  in  the  "QUERY_. . . "  files  listed  in  Attachment  2. 

The  "LIST_. . . " - type  of  forms  shown  in  Attachment  2  were  designed 
to  provide  the  "look-up"  table  capability  described  in  the  ARMS  User's 
Guide  and  required  by  paragraph  3.2.3  above.  The  "UPDATE_. . . " - type  of 
forms  provide  the  database  administration  personnel  with  the  capability 
to  add,  change,  and  delete  records  from  the  ARMS'  tables,  as  required  by 
paragraph  3. 2. 2. 4.1.  The  fourth  and  final  form  type,  the  "HELP_..."- 
series,  is  described  below. 

4 . 4  Help  Facilities  .  A  limited  help  system  was  implemented  with  this 
version  of  the  prototype.  Requesting  help  from  the  system  is  as  easy  as 
pressing  "0"  on  the  keypad  (<KP0>)  during  any  menu,  query,  or 
information  record  display.  Pressing  <KP0>  when  a  menu  screen  is 
displayed  provides  the  user  with  information  about  menu  options,  while 
pressing  <KP0>  during  the  display  of  query  or  information  records 
presents  a  layout  of  active  keys  for  use  within  the  current  function. 
Additional  help  is  provided  on  many  of  the  screens  in  the  form  of  "text 
boxes"  and  one- line  messages  that  appear  in  the  inverse  video  at  the 
bottom  of  most  screens.  The  ARMS  User's  Guide  contains  some  specific 
examples  of  the  help  information  provided  by  the  current  prototype 
system.  The  "HELP_ . . . " - type  of  forms  shown  in  Attachment  2  contain  the 
help  screens  for  the  individual  menu  options . 
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SECTION  5 .  ENVIRONMENT 


5 ■ 1  Equipment  Environment .  The  prototype  ARMS  is  currently  hosted  on  a 
Digital  Electronics  Corporation  (DEC)  VAX/VMS  8650  processor  with  32 
megabytes  of  internal  memory .  Other  than  a  personal  computer  or  other 
VTlOO-capable  terminal  connected  to  the  AFITNET,  there  are  currently  no 
special  peripherals  required  to  access  and  operate  the  ARMS .  Dedicated 
storage  space  and  other  system  resources  may  be  required  in  the  future, 
but  none  have  been  determined  to  date . 

5 ■ 2  Support  Software  Environment .  The  following  software  was  used  to 
develop  the  prototype  system: 


A. 

ORACLE,  version  6 . 

0 

B. 

SQL* FORMS, 

version  2.3.31 

C. 

SQL*MENU, 

version 

4.1.16 

D. 

SQL* PLUS, 

version 

3 . 0 . 9 . 4 . 1 

5 ■ 3  Interfaces .  Currently,  there  are  no  other  systems  that  interface 
with  the  prototype  ARMS.  If  a  production-quality  system  is  eventually 
developed,  links  to  the  AFIT  Student  Information  System  (AFITSIS)  and 
the  Integrated  Library  System  (ILS)  should  be  considered. 

5 ■ 4  Security .  The  ARMS  is  not  designed  to  contain  or  process 
classified  information.  However,  the  current  prototype  provides  the 
following  information  protection  safeguards : 

A.  Users  are  required  to  "login"  to  the  VAX/VMS  Cluster  using 
their  personal  "username"  and  "password." 

B.  Users  are  then  required  to  enter  their  ORACLE  "username"  and 
"password. " 

C.  Access  to  sensitive  data  elements  is  restricted  to  a  specified 
set  authorized  personnel . 
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SECTION  6.  COST  FACTORS 


Cost  factors  are  not  addressed  in  this  version  of  the  functional 
description  because  they  could  not  reasonably  be  considered  during  the 
initial  prototype  development  of  the  ARMS .  One  recommendation  for 
future  research  includes  the  performance  of  a  complete  cost-benefit 
analysis  to  determine  if  a  production-quality  system  should  be  pursued. 


SECTION  7.  SYSTEM  DEVELOPMENT  PLAN 


7 ■ 1  Initial  Prototype  Development  and  Results .  Development  of  the 
initial  prototype  ARMS  was  accomplished  using  the  seven  research 
objectives  described  in  Chapter  III  of  the  AFIT  thesis  referenced  in 
paragraph  1.2. A.  While  Chapters  IV  and  V  discuss  the  studies  results 
and  conclusions,  respectively. 

7 . 2  Follow-On  Recommendations .  Chapter  V  of  the  AFIT  thesis  referenced 
in  paragraph  1.2. A  also  provides  many  recommendations  for  improving  the 
current  prototype  system  and  performing  corollary  studies .  The 
interested  reader  should  thoroughly  review  the  thesis  and  its  appendices 
for  additional  information. 


K-21 


Attachment  1  -  Prototype  ASMS  Data  Dictionary 


Listed  below  are  the  primary  and  supporting  tables  for  the 
prototype  ARMS.  The  tables  under  each  category  are  listed  in 
alphabetical  order. 


part  1  -  fSIUftRX  IftBlES 


Table  Name:  ADVISOR 

Purpose;  This  table  is  used  to  store  information  about  advisors  of  past 
and  current  thesis  efforts.  Data  in  this  table  is  accessible 
through  the  Research  Management  System  or  Database 
Administration  Subsystem. 


FIELD  NAME 

ADVISOR  LASTNAME 

FIELD  TYPE 
Character 

SIZE 

20 

ADVISOR  FIRSTNAME 

Character 

15 

ADVISOR_MIDDLEINIT 

Character 

3 

ADVISOR_RANK 

Character 

8 

ADV I S 0R_0RG_0FC S YM 

Character 

20 

ADVISOR  PHONE  LOCAL 

Character 

8 

ADVISING_STATUS 

Character 

1 

STATUS_DATE 

Character 

4 

LAST  ADVISED 

Char'.cter 

4 

INTEREST  AREA  1 

Character 

30 

INTEREST  AREA  2 

Character 

30 

INTEREST  AREA  3 

Character 

30 

INTEREST  AREA  4 

Character 

30 

INTEREST  AREA  5 

Character 

30 

INTEREST  AREA  6 

Character 

30 

ADVIS0R_ADDRESS_L1 

Character 

50 

ADVIS0R_ADDRESS_L2 

Character 

50 

ADVISOR  COMMENTS  LI 

Character 

60 

ADVISOR  COMMENTS  L2 

Character 

60 

ADVISOR  COMMENTS  L3 

Character 

60 

DESCRIPTION/POSSIBLE  VALUES 
Thesis  advisor's  last  name 
Thesis  advisor's  first  name 
Thesis  advisor's  middle  initial 
or  may  contain  NMI  (no  middle 
initial ) 

Military  rank  or  may  contain 
CIVILIAN  for  non-military 
Thesis  advisor's  organization 
and  office  symbol 
Thesis  advisor's  local  phone  = 
May  contain:  'Q'  for  fully 
qualified,  'I'  for  intern,  or 
'A'  for  adjunct  (See  LSOI  50-11 
for  more  information. ) 

Academic  year  assigned  their 
advising  status 

Academic  year  they  last  advised 
Area  of  interest  to  advisor 
Area  of  interest  to  advisor 
Area  of  interest  to  advisor 
Area  of  interest  to  advisor 
Area  of  interest  to  advisor 
Area  of  interest  to  advisor 
Building/street  address  of 
advisor  if  not  a  faculty  member 
City  or  base,  state,  and  zip 
code  of  non- faculty  advisor 
Space  for  miscellaneous  comments 
Space  for  miscellaneous  comments 
Space  for  miscellaneous  comments 


Table  Name;  COMPONENT 

Purpose:  This  table  is  used  to  store  information  about  thesis 

components  (AKA  research  products) .  Data  in  this  table  is 
accessible  through  the  Research  Products  Reuse  Subsystem  and 
Database  Administration  Subsystem. 
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FIELD  NAME 
THESIS_ID_NR 

FIELD  TYPE 
Character 

COMPONENT_POC_LASTNAME 

Character 

POC  DEPARTMENT 

Character 

COMPONENT  TITLE  LI 

Character 

COMPONENT  TITLE  L2 

Character 

COMPONENT  TITLE  L3 

Character 

COMPONENT_TYPE 

Character 

DATE_SUBMITTED 

Character 

REUSED_COMPONENT 

Character 

COMPONENT  COMMENTS 

LI 

Character 

COMPONENT  COMMENTS 

'L2 

Character 

ABSTRACT_LOCATION 

Character 

COMPONENT  LOCATION 

Character 

SIZE  description/possible  values 

20  Thesis  identification  number 
(AKA  thesis  designator) 

20  One  of  the  thesis  advisors  for 
the  study  that  proauced  the 
component  product 
3  Thesis  advisor's  department 
60  First  part  of  component  title 
60  Second  part  of  component  title 
60  Third  part  of  component  title 
20  Type  of  component  (i.e.  Survey, 
Questionnaire,  Statistical 
Model,  etc . ) 

9  Date  component  formally  placed 
into  the  ARMS  for  reuse 
1  Control  field  to  indicate  if 
the  component  was  reused  from 
another  study  ('Y'es  or  'N'o) 

60  Space  for  miscellaneous  info 
60  Space  for  miscellaneous  info 
25  Name/location  of  text  file 

containing  the  thesis  abstract 
40  Name/location  of  text  file 

containing  electronic  copy  of 
the  component  (if  applicable) 


Table  Name:  SPONSOR 

Purpose:  This  table  is  used  to  store  information  about  thesis  sponsors. 

Data  in  this  table  is  accessible  through  the  Research 
Management  System  or  Database  Administration  Subsystem. 


FIELD  NAME 

FIELD  TYPE 

SIZE 

DESCRIPTION/POSSIBLE  VALUES 

THESIS_ID_NR 

Character 

20 

Thesis  identification  number 
(AKA  thesis  designator) 

SP0NS0R_P0C 

Character 

50 

Sponsoring  agency's  point  of 
contact  (POC) 

SPONSOR_ORG_OFCSYM 

Character 

25 

Organization  and  office  symbol 
of  sponsor 

SP0NS0R_ADDRESS_L1 

Character 

50 

First  part  of  sponsoring 
agency's  address 

SP0NS0R_ADDRESS_L2 

Character 

50 

Second  part  of  sponsoring 
agency's  address 

SPONSOR_PHONE_COMM 

Character 

13 

Commercial  telephone  number  of 
sponsoring  agency's  POC 

SPONSOR_PHONE_DSN 

Character 

8 

DSN  telephone  number  of 
sponsoring  agency's  POC 

FUND I NG_PROV IDED 

Character 

1 

Control  field  to  indicate  if 
funding  was  provided  ('Y'es  or 
'N'o) 

Amount  of  funding  received  from 
sponsoring  agency 

FUNDING_AMOUNT 

Character 

6 

COST_DEFER_RQSTD 

Character 

1 

Control  field  to  indicate  if  a 
cost  avoidance  estimate  request 
has  been  sent  ('Y'es  or  'N'o) 

COST_DEFER_RECVD 

Character 

1 

Control  field  to  indicate  if 
the  estimate  has  been  received 
('Y'es  or  'N'o) 

COST  DEFER  VALUE 

Number 

6 

Estimate  cost  avoidance  amount 
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(SPONSOR  table  definition  continued) 

SPONSOR_COMMENTS_Ll  Character  60  Space  for  miscellaneous  comments 

SPONSOR_COMMENTS_L2  Character  60  Space  for  miscellaneous  comments 

SPONSOR_COMMENTS_L3  Character  60  Space  for  miscellaneous  comments 

Table  Name :  STUDENT 

Purpose:  This  table  is  used  to  store  information  about  graduate 

students  (AKA  thesis  authors) .  Only  a  portion  of  the  data 
items  in  this  table  is  currently  used.  However,  the  type  of 
information  in  this  table  could  prove  valuable  as  the  Research 
Management  Subsystem  matures.  Currently,  the  data  in  this 
table  is  primarily  accessible  through  the  Database 
Administration  Subsystem. 


EIEIO  name 

FIELD  TYPE 

SIZE 

PESCBIfTIQH/gQSSlBEE  VALUES 

STUDENT  LASTNAME 

Character 

20 

Student ' s  last  name 

STUDENT  FIRSTNAME 

Character 

15 

Student's  first  name 

STUDENT_MIDDLEINIT 

Character 

3 

Student ' s  middle  initial  or  may 
contain  NMI  (no  middle  initial) 

STUDENT_RANK 

Character 

8 

Military  ran)c  or  may  contain 
CIVILIAN  for  non-military 

STUDENT  SSAN 

Character 

11 

Student's  social  security  ?? 

DEGREE_PR0GRAM_1D 

Character 

3 

Student's  three -letter  degree 
program  designator 

PROGRAM  OPTION 

Character 

25 

Specific  graduate  degree  program 
option,  if  applicable 

GRADUATION_YEAR 

Character 

4 

Academic  year  of  student's 
scheduled  graduation 

GRADU AT I ON_MONTH 

Character 

1 

First  letter  of  the  student's 
scheduled  month  of  graduation 
(may  contain  an  'S'  for  Septem¬ 
ber  or  'D'  for  December) 

THESIS_1D_NR 

Character 

20 

Thesis  identification  number 
(AKA  thesis  designator) 

THESIS_APPROVED 

Character 

1 

Control  field  to  indicate  if 
thesis  is  ongoing  ('Y'es  or 
■N'o) 

Control  field  to  indicate  if  the 
thesis  was  team  effort  ('Y'es  or 
’N’o) 

Field  to  contain  student's  grade 
for  the  first  quarter  of  thesis 
work 

TEAM_THESIS 

Character 

1 

FIRST_QTR_GRADE 

Character 

2 

SECOND_QTR_GRADE 

Character 

2 

Field  to  contain  student ' s  grade 
for  the  second  quarter  of  thesis 
work 

THIRD_QTR_GRADE 

Character 

2 

Field  to  contain  student's  grade 
for  the  third  quarter  of  thesis 
work 

STUDENT  COMMENTS  LI 

Character 

60 

Space  for  miscellaneous  comments 

STUDENT  COMMENTS  L2 

Character 

60 

Space  for  miscellaneous  comments 

STUDENT  COMMENTS  L3 

Character 

60 

Space  for  miscellan-. -ous  comments 

Table  Name :  THESIS 

Purpose:  This  table 

is  used  to 

store 

information  about  each  graduate 

thesis.  Data  in  this 

table 

is  accessible  through  all 

subsystems 

except  the 

Research  Products  Reuse  Subsystem. 
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FIELD  WAI>tE 

FIELD  TYPE 

SIZE 

DESCRIPTION/POSSIBLE  VALUES 

THESIS_ID_NR 

Character 

20 

Thesis  identification  number 
(AKA  thesis  designator) 

DATE  PUBLISHED 

Character 

9 

Thesis  publication  date 

THESIS  TITLE  LI 

Character 

60 

First  part  of  thesis  title 

THESIS  TITLE  L2 

Character 

60 

Second  part  of  thesis  title 

THESIS  TITLE  L3 

Character 

60 

Third  part  of  thesis  title 

SUBJECT_TERM_1 

Character 

30 

Applicable  DTIC  subject  term  for 
the  thesis  (more  than  one  may 
apply- -as  shown  below) 

SUBJECT_TERM_2 

Character 

30 

Applicable  DTIC  subject  term  for 
the  thesis 

SUBJECT_TERM_3 

Character 

30 

Applicable  DTIC  subject  term  for 
the  thesis 

SUBJECT_TERM_4 

Character 

30 

Applicable  DTIC  subject  term  for 
the  thesis 

SUBJECT_TERM_5 

Character 

30 

Applicable  DTIC  subject  term  for 
the  thesis 

SUBJECT_TERM_6 

Character 

30 

Applicable  DTIC  subject  term  for 
the  thesis 

CONTINUING_STUDY 

Character 

1 

Control  field  to  indicate  if 
thesis  continues  a  previous 
study  ('Y'es  or  'N'o) 

SPONSORED_STUDY 

Character 

1 

Control  field  to  indicate  if  the 
thesis  was  a  sponsored  study 
( 'Y’es  or  ’N'o) 

THESIS_APPROVED 

Character 

1 

Control  field  to  indicate  if 
thesis  is  ongoing  ('Y'es  or 
'N’o) 

Control  field  to  indicate  if  the 
thesis  was  selected  for  an  award 
( 'Y'es  or  'N'o) 

AW ARD_W INNER 

Character 

1 

AWARD_CODE 

Character 

1 

First  letter  of  award  received, 
if  applicable 

CLASSIFICATION 

Character 

15 

Security  classification  of 
thesis 

DTIC_NR 

Character 

15 

DTIC  number  assigned  to  thesis 
if  it  is  archived  through  that 
agency 

DISTRIBUTION_CODE 

Character 

9 

Thesis  distribution  code 
assigned  by  the  advisors 

D I STRI BUT I ON_STMT_L 1 

Character 

60 

First  part  of  distribution 
statement  for  the  thesis 

DISTRIBUTION_STMT_L2 

Character 

60 

Second  part  of  distribution 
statement  for  the  thesis 

DI STR I BUT I ON_STMT_L  3 

Character 

60 

Third  part  of  distribution 
statement  for  the  thesis 

DISTRIBUTION_STMT_L4 

Character 

60 

Fourth  part  of  distribution 
statement  for  the  thesis 

OTHER  COMMENTS  LI 

Character 

60 

Space  for  miscellaneous  comments 

OTHER  COMMENTS  L2 

Character 

60 

Space  for  miscellaneous  comments 

OTHER  COMMENTS  L3 

Character 

60 

Space  for  miscellaneous  comments 

ABSTRACT  LOCATION 

Character 

25 

Name/location  of  text  file 
containing  the  thesis  abstract 
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Table  Name:  TOPIC 

Purpose:  This  table  is  used  to  store  information  about  new  research 

requests  (AKA  topics) .  Data  in  this  table  is  accessible 
through  the  Research  Topic  Selection  Subsystem  and  the 
Research  Management  Subsystem. 

FIELD  NAME  FIELD  TYPE  SIZE  DESCRIPTION /POSSIBLE  VALTTES 


TOPIC_NR 

Character 

6 

Topic  identification  number 
assigned  by  LSC  using  a  year- 
sequential  number  format  (YY- 
NNN) 

TOPIC  TITLE  LI 

Character 

60 

First  part  of  topic  title 

TOPIC  TITLE  L2 

Character 

60 

Second  part  of  topic  title 

TOPIC  TITLE  L3 

Character 

60 

Third  part  of  topic  title 

D ATE_SUBM1 TTED 

Character 

9 

Date  topic  initially  received  bv 
LSC 

EXTERN AL_SOURCE 

Character 

1 

Control  field  to  indicate  if  the 
topic  was  generated  from  an 
agency  outside  of  AFIT  ('Y'es  or 
•N'o) 

Control  field  to  indicate  if 
this  request  has  been  previously 
researched  ('Y'es  or  'N'o) 

TOPIC_USED 

Character 

1 

FACULTY_POC_LASTNAME 

Character 

20 

Internal  point  of  contact  (POC) 
that  has  reviewed  and  volun¬ 
teered  to  advise  the  topic 

FACULTY  POC 

DEPARTMENT 

Character 

3 

Three  letter  department/direc¬ 
torate  of  faculty  POC 

SUBJECT_TERM_1 

Character 

30 

Applicable  DTIC  subject  term  for 
the  topic  (more  than  one  may 
apply- -as  shown  below) 

SUBJECT_TERM_2 

Character 

30 

Applicable  DTIC  subject  term  for 
the  topic 

SUBJECT_TERM_3 

Character 

30 

Applicable  DTIC  subject  term  for 
the  topic 

SUBJECT_TERM_4 

Character 

30 

Applicable  DTIC  subject  term  for 
the  topic 

SUBJECT_TERM_5 

Character 

30 

Applicable  DTIC  subject  term  for 
the  topic 

SUBJECT_TERM_6 

Character 

30 

Applicable  DTIC  subject  term  for 
the  topic 

NOMI NATOR_NAME 

Character 

50 

Nominating  agency's  point  of 
contact 

NOMINATOR_ORG_OFCSYM 

Character 

25 

Organization  name  and  office 
symbol  of  nominator 

NOMI NATOR_ADDRES S_L 1 

Character 

50 

First  part  of  nominating 
agency's  address 

NOMI N ATOR_ADDRES S_L 2 

Character 

50 

Second  part  of  nominating 
agency's  address 

NOMI N ATOR_PHONE_COMM 

Character 

13 

Commercial  telephone  number  of 
nominating  agency's  POC 

NOMI NATOR_PHONE_DSN 

Character 

8 

DSN  telephone  number  of 
nominating  agency's  POC 

TOPIC  COMMENTS  LI 

Character 

60 

Space  for  miscellaneous  comments 

TOPIC  COMMENTS  L2 

Character 

60 

Space  for  miscellaneous  comments 

ABSTRACT  LOCATION 

Character 

25 

Name/location  of  text  file 
containing  the  topic  abstract 
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PART  II  - 


tables 


Table  Name:  ADVISOR_HISTORY 

Purpose:  This  table  is  used  to  store  information  about  the  theses 

the  advisor  has  been  involved  with.  This  information  is 
currently  updated  through  the  Database  Administration 
Subsystem  and  is  displayed  by  all  subsystems  that  present 
information  about  theses.  The  foreign  key  ' THESISID_NR'  is 
what  relates  the  advisor  back  to  the  appropriate  thesis  record 
and  vice  versa . 


FIELD  NAME 

ADVI SOR_LASTNAME 

THESIS_1D_NR 

ADVISOR  OR  READER 


FIELD  TYPE  SIZE 
Character  20 
Character  20 

Character  7 


DESCRIPTION/POSSIBLE  VALUES 
Thesis  advisor's  last  name 
Thesis  identification  number 
(AKA  thesis  designator) 
Advisor's  role  for  the 
specified  thesis 


Table  Name :  COMPONENT_TYPES 
Purpose:  This  table  stores  a  unique 

used  as  a  look-up  table  by 
Subsystem  to  assist  in  the 
' component  type . ' 


list  of  'component  types. '  It  is 
the  Research  Products  Reuse 
formulation  of  queries  by 


FIELD  NAME  FIELD  TYPE  SIZE 

COMPONENT  TYPE  Character  20 


Table  Name:  CONT_STUDY_SUBJECTS_LIST 

Purpose:  This  table  stores  a  unique  list  of  subject  terms  applicable  to 

theses  categorized  as  continuing  studies .  It  is  used  as  a 
look-up  table  by  the  Research  Topic  Selection  Subsystem  and 
Research  Management  Subsystem  to  assist  in  the  formulation  of 
queries  by  'subject  term.' 


FIELD  NAME  FIELD  TYPE  SIZE 

SUBJECT  TERM  Character  30 


Table  Name :  CRITERIA 

Purpose:  This  table  is  a  dummy  table  used  by  several  of  the  query 

forms.  It  serves  only  as  a  temporary  storage  location  for 
user  inputs . 


FIELD  NAME 

FIELD  TYPE 

SIZE 

SUBJECT  TERM 

Character 

30 

DEPARTMENT 

Character 

20 

DEGREE  PROGRAM  ID 

Character 

3 

AUTHOR  LASTNAME 

Character 

20 

ADVISOR  LASTNAME 

Character 

20 

TITLE 

Character 

30 

SPONSORED 

Character 

1 

CONTINUING 

Character- 

1 

THESIS  DESIGNATOR 

Character 

20 

DTIC  NR 

Character 

15 

TOPIC  NR 

Character 

6 

SOURCE 

Character 

1 

NOMINATOR  ORG 

Character 

25 
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Table  Name:  INTEREST_AREA_LIST 

Purpose:  This  table  stores  a  unique  list  of  advisor  interest  areas. 

It  is  used  as  a  look-up  table  by  the  Research  Management 
Subsystem  to  assist  in  the  formulation  of  thesis  advisor 
queries  by  ' interest  areas . ' 

FIELD  NAME  FIELD  TYPE  SIZE 

INTEREST  AREA  Character  30 


Table  Name:  ONGOING_THESIS_SUBJECTS_LIST 

Purpose:  This  table  stores  a  unique  list  of  subject  terms  applicable  to 

theses  categorized  as  ongoing.  It  is  used  as  a  look-up  table 
by  the  Research  Topic  Selection  Subsystem  to  assist  in  the 
formulation  of  queries  by  'subject  term.' 

FIELD  NAME  FIELD  TYPE  SIZE 

SUBJECT  TERM  Character  30 


Table  Name:  SPONSORLIST 

Purpose:  This  table  stores  a  unique  list  of  sponsor  organization/office 

symbol  values.  It  is  used  as  a  look-up  table  by  the  Research 
Management  Subsystem  to  assist  in  the  formulation  of  queries 
by  'sponsor  organization.' 

FIELD  NAME  FIELD  TYPE  SIZE 

SPONSOR  ORG  OFCSYM  Character  25 


Table  Name:  SPONSORED_STUDY_SUBJECTS_LIST 

Purpose:  This  table  stores  a  unique  list  of  subject  terms  applicable  to 

theses  categorized  as  sponsored.  It  is  used  as  a  look-up 
table  by  the  Research  Topic  Selection  Subsystem  to  assist  in 
the  formulation  of  queries  by  'subject  term.' 

FIELD  NAME  FIELD  TYPE  SIZE 

SUBJECT_TERM  Character  30 

Table  Name:  THESIS_SUBJECTS_LIST 

Purpose:  This  table  stores  a  unique  list  of  subject  terms  applicable  to 
all  theses  in  the  THESIS  table.  It  is  used  as  a  look-up  table 
by  the  Research  Topic  Selection  and  Research  Management 
Subsystems  to  assist  in  the  formulation  of  queries  by  'subject 
term.  ' 

FIELD  NAME  FIELD  TYPE  SIZE 

SUBJECT  TERM  Character  30 


Table  Name:  TOPIC_SUBJECTS_LIST 

Purpose:  This  table  stores  a  unique  list  of  subject  terms  applicable  to 
all  topics  in  the  TOPIC  table.  It  is  used  as  a  look-up  table 
by  the  Research  Topic  Selection  Subsystem  to  assist  in  the 
formulation  of  queries  by  'subject  term.' 

FIELD  NAME  FIELD  TYPE  SIZE 

SUBJECT  TERM  Character  30 
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Table  Name:  TOPIC_HISTORY 

Purpose:  This  table  is  used  to  store  information  on  the  use  of  specific 

topics.  It  is  not  currently  used  by  any  of  the  subsystems  at 
this  time,  but  could  be  used  in  future  prototype  enhancement 
efforts . 


FIELD  NAME 

TOPIC_NR 

THESIS_ID_NR 

NOMINATOR  NOTIFIED 


TOPIC_HISTORy 
C0MMENTS_L1 
TOPIC_HISTORY 
COMMENTS  L2 


field  TYPE  SI^E  DESCRIPTION/POSSIBLE  VALUES 
Character  6  Topic  identification  number 

Character  20  Thesis  identification  number 

that  used  the  topic 

Character  1  Control  field  to  indicate  if 

the  topic's  nominator  has  been 
notified  that  the  topic  will 
be  used  ('Y'es  or  'N'o) 
Character  60  Line  1  of  topic  history 
comments 

Character  60  Line  2  of  topic  history 
comments 
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Attachment  2  -  Prototype  ARMS  Menu/Forms  Tree 


Listed  below  is  the  menu  structure  for  the  initial  prototype  ARMS, 
list  of  applicable  SQL*FORMS (TM) -generated  forms  for  each  menu  option 
also  included  to  provide  an  integrated  view  of  the  system. 


ARMS  Main  Menu 

1  -  Research  Topic  Selection  Subsystem  Menu 

—  1  -  Review  All  Thesis  Records 

HELP_CRITERIA_KEYS.1NP 
HELP  THESIS.KEYS.INP 
LIST_THESIS_SUBJECTS.INP 
QUERY_THESES_ALL.INP 
QUERY_THESES_BY_SUBJECT.1NP 

—  2  -  Review  Continuing  Studies  Records 

HELP.CRITERIA  KEYS.INP 
HELP.THESIS  MIYS.INP 
LIST_CONT_sfUDY_SUBJECTS.INP 
QUERY_THESES.CONT_STUDY.INP 

—  3  -  Review  Ongoing  Theses  Records 

HELP_CRITERIA_KEYS.IN? 

HELP  THESIS  KEYS.INP 
LIST.ONGOING  THESIS  SUBJECTS.INP 
QUERY.THESES.ONGOING.INP 

—  4  -  Review  Sponsored  Theses  Records 

HELP_CRITERIA_KEYS.INP 

HELP_THESIS_KE\'S.INP 

L1ST_SP0NS0RED_STUDY_SUBJECTS.INP 

QUERY.THESES.SPONSORED.INP 

—  5  -  Review  New  Research  Requests 

HELP.CRITERIA.KEYS.INP 
HELP.TOPIC  KEYS.INP 
LIST.TOPIC  SUBJECTS.INP 

query_top1cs_by_subject.  INP 

—  6  -  Return  to  Previous  Menu 

2  -  Research  Products  Reuse  Subsystem  Menu 

HELP.CRITERLA  KEYS.INP 
HELP  TOPIC  KEYS.INP 
LIST.TOPIC.SUBJECTS.  INP 
QUERY  TOPICS  BY  SUBJECT.  INP 


(Continued  on  next  page) 
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3  -  Research  Management  Subsystem  Menu 

1  -  Review  Continuing  Research  Information 

HELP  CRITERL4  KEYS.INP 
HELP.THESIS  KEYS.INP 
LIST.CONT  STUDY  SUBJECTS.INP 

query_theses_c6nt_study.inp 

2  -  Review  Research  Sponsorship  Information 

HELP  CRITERIA  KEYS.INP 
HELP  SPONSOR  KEYS.INP 
LIST  SPONSORS.INP 
QUERY.SPONSORS.INP 

3  -  Review  Thesis  Advisor  Qualifications 

HELP  CRITERIA  KEYS.INP 
HELP  ADVISOR.KEYS.INP 
LIST  iNTEREST_AREAS..INP 
QUERY_ADVISORS.INP 

4  -  Review  Thesis  Completion  Status 

This  option  is  diplayedon  the  menu  as  another  example  of  the 
types  of  items  that  could  be  added  to  this  subsystem.  No  forms 
were  generated  for  this  option,  but  the  necessary  data  to  generate 
them  is  contained  in  the  existing  ARMS  tables. 

5  -  Review  Research  Publication  Information 

This  option  is  diplayed  on  the  menu  as  another  example  of  the 
types  of  items  that  could  be  added  to  this  subsysteno.  No  forms 
were  generated  for  this  option,  but  the  necessary  data  to  generate 
them  is  contained  in  the  existing  ARMS  tables. 

6  -  Return  to  Previous  Menu 


4  -  Database  Administration  Subsystem  Menu 


1  -  Add/Change/Delete  Records 

UPDATE  ADVISOR  INFO.INP 
UPDATE_COMPONENT_INFO.INP 
UPDATE_SPONSOR_INFO.INP 
UPDATE  THESIS  INFO.INP'* 
UPDATE  TOPIC.WO.INP 


2  -  Perform  Special  Queries 

This  option  initiates  a  SQL*PLUS  session  and  allows 
personnel  knowledgeable  of  the  ARMS  tables  to  conduct 
complex  SQL  searches. 


3  -  Return  to  Previous  Menu 


5  -  Exit  (tbe  ARMS) 


*  -  The  UPDATE_THESIS_INFO.INP  form  permits  the  database  administrator  to  add, 
change,  and  delete  records  from  the  following  tables:  THESIS,  ADVISOR  HISTORY, 
and  STUDENT 
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